Creating an invoice records the billing information. Validating it checks a defined set of rules. Sending it transfers a document through a chosen route. These stages are connected, but success at one does not establish success at the others. A complete draft can be invalid for a recipient’s profile, and a valid file can still be delivered to the wrong place.
Use named stages and clear evidence in your process. This is useful even when one application eventually handles several stages behind the scenes. The first-invoice workflow begins with recipient requirements precisely because those requirements influence what must be created, checked and delivered.
Creation establishes the document’s content
During creation, you identify the seller and buyer, allocate a reference, enter dates and describe the supplied items. You record quantities, prices, confirmed tax information and payment instructions. The resulting draft should reflect the commercial facts and the intended recipient’s requirements.
A creator can calculate amounts and display a readable preview without implementing a recognised structured format. For example, a form may hold labelled fields internally and export its own JSON. That is useful application data, but another system needs an agreed mapping before it can treat those fields as its expected invoice message.
EInvoiceCreator currently operates at this preparation level, with application field checks and ordinary exports. It does not generate EN 16931-conformant, XRechnung, Factur-X or Peppol documents. Do not label the creation stage “standards complete” simply because the preview contains a seller, customer and total.
Field checking establishes only the checks performed
The current field checker looks for required values, supported selections, valid calendar dates, due-date order, numeric precision and certain category/reason combinations. It can direct you to a missing buyer name or an unsupported percentage. It cannot know whether the entered name is the correct legal buyer.
That distinction matters when describing a result. “Application field checks passed” tells another person what happened. “Invoice validated” can be misleading if the person assumes schema or business-rule validation was performed. Always identify the rule set and version when a validation result is part of a hand-off.
For a fictional invoice, entering a non-empty but incorrect order reference may remove a required-field error. It does not prove that the recipient can match the order. The source agreement and customer instructions remain part of the evidence needed for a useful document.
Formal validation evaluates a specified representation
Formal invoice validation needs an actual target specification and a file mapped into the required structure. Depending on the workflow, checks can concern XML structure, permitted values, mandatory information, calculations and profile-specific business rules. Different layers can reveal different problems.
The European Commission explains that its semantic invoice model is bound to specified message syntaxes and supported by validation artefacts. An arbitrary XML file is therefore not equivalent to a file that has been correctly mapped and checked under the relevant profile. The specification’s edition and the recipient’s accepted version also matter.
A formal result should identify what was checked and any remaining errors or warnings. Even a successful result does not establish every commercial or legal fact. A validator cannot generally confirm that a customer approved ten hours of work or that a payment account belongs to the intended supplier.
Delivery establishes a transfer event
Delivery uses the agreed channel, such as an email process, portal or network integration. A format specification does not itself send a file, and a transport channel does not automatically repair a document’s business content. Keep destination details and document requirements separate in the preparation records.
When a delivery service provides an acknowledgement, understand what the acknowledgement means. It may show that a file was uploaded or transmitted, not that the customer’s accounts-payable process accepted the amount. Network transport, document validation and business processing can produce different statuses.
The current creator has no email-sending service, Peppol connection or tax-authority submission integration. Downloading an export leaves delivery with you or your chosen external workflow. Do not tell a customer that an invoice has been submitted because a local file appeared in the browser’s downloads.
Acceptance can involve further business checks
A recipient may compare the invoice with an order, delivery, contract, budget or supplier record. A document that passes technical checks may still contain an unrecognised buyer reference or an amount the customer disputes. This feedback needs a commercial investigation, not necessarily a change to the file’s syntax.
Suppose a fictional supplier uploads a correctly formatted invoice to a portal and receives a receipt. The customer later reports that the billed entity is wrong. The receipt remains evidence of the transfer, but it is not evidence that the invoice was correct for that buyer. Preserve the feedback and follow an appropriate correction process.
The manual review responsibilities describe facts that should be confirmed before reaching this stage. Assign responsibility for unresolved decisions so that a successful technical step does not conceal an unreviewed business question.
Keep a stage-based hand-off
A useful hand-off identifies the prepared invoice version, application checks performed, external validation if any, intended delivery route and remaining action. Keep statuses specific rather than using one green label for the whole process.
When one stage fails, investigate that stage first. A missing identifier needs a data or mapping correction; a wrong destination needs a delivery correction. Preserving the distinction helps you fix the actual problem without repeatedly editing unrelated fields or overstating what the current tool has completed.