Moving from a paper invoice to structured data means identifying what each value represents, entering it in the appropriate field and checking the resulting record against the original. Scanning a document produces an image. Typing its text into one notes box produces text. Neither step alone creates a structured invoice that another system can process according to an agreed format.
Treat the original as a source record, not a ready-made field map. Printed layouts often place an order number, bank reference and tax identifier near one another without explaining their different purposes. The first-invoice preparation workflow helps you gather missing information before deciding whether the old document contains everything needed for the new task.
Decide whether you are recording or issuing
First establish your purpose. You may be recording an old invoice for internal analysis, preparing data for an external conversion process, or creating a new document for a new supply. These activities should not be confused. Re-entering a historic invoice does not automatically justify issuing a second invoice with the same commercial effect.
Keep the original reference and dates when preserving an existing record. Do not replace them with today’s date merely because a blank form suggests it. If an issued invoice needs a correction, follow the applicable correction process and use software that supports the necessary document type. The current creator does not implement credit notes or a formal issued-document ledger.
Note the original filename, page count and location in your own records. If the paper is difficult to read, ask for a clearer copy rather than interpreting an ambiguous digit as a fact. The original evidence remains important when another person needs to review how a value entered the structured record.
Identify information by meaning
Separate seller and buyer details first. A delivery address may belong to a warehouse while the bill is addressed to a different legal entity. An email in the footer may be a sales contact rather than the billing contact. Write down these roles instead of relying on where text appears on the page.
Identify the invoice number, order reference, issue date, due date and any supply period. Do not combine these into a single reference field. If the editor has no dedicated location for one required value, record the limitation for the next stage rather than pretending the available box has a different meaning.
For every line, extract the description, quantity, unit, unit price, discount and tax information. Be especially careful when the printed amount is a line total rather than a unit price. Entering a line total as the price and then multiplying it by the printed quantity can overstate the charge dramatically.
Reconcile a small example
Suppose a fictional paper invoice shows three storage boxes, EUR 24 per box and a line amount of EUR 72 before tax. The structured entries are quantity 3, unit “box” and unit price 24.00. Entering 72.00 as the unit price would create EUR 216 before tax, even though the copied amount looked familiar.
If the same paper shows a EUR 10 document-level discount, do not invent a percentage on one line simply to force the final total to match. The current creator supports line-level percentage discounts, not that complete document-level allowance structure. Preserve the actual allowance and use an appropriate mapper or invoicing system for the final representation.
Compare subtotal, tax and payable amount separately. A matching grand total can hide two offsetting errors. Where a discrepancy remains, check units, discount basis, decimal separators and rounding before adjusting any value. The source document, not the desired visual result, should govern the review.
Understand the role of extraction tools
Optical character recognition can suggest text from a scan, and other extraction software may suggest fields. Treat suggestions as unverified draft data. A successful character extraction can still put the delivery address in the buyer field or confuse a total with a unit price. Sensitive invoice data should not be uploaded to an external service without understanding and authorising that processing.
EInvoiceCreator currently has no paper-image upload, OCR or automatic PDF extraction. Its import reads supported application JSON drafts. Do not expect a scanned document or arbitrary accounting export to populate the form. Manual entry can prepare the ordinary invoice information supported by the current model.
The machine-readable invoice explanation describes why labels and agreed structure matter after extraction. The distinction is particularly important when a recipient has requested a named XML profile rather than a readable copy.
Prepare for the actual target format
Once the values are reviewed, identify the external format, profile and version the recipient requires. A paper document may omit identifiers or structured references that the target workflow needs. Obtain those facts from the appropriate business contact; a conversion step cannot safely invent them.
The current creator can help review the basic data and calculate its supported amounts. Printable output and application JSON remain preparation outputs, not verified standards conversions. A final standards-based invoice requires correct mapping, the relevant validation and the required delivery process. Keep those remaining tasks visible so an accurately transcribed record is not mistaken for a finished submission.