The exchange is a chain of states
A structured invoice can pass through creation, transformation, validation, routing, receipt and business processing. Each stage answers a different question. A “sent” status from the supplier's ERP may mean only that it handed a file to a connector. It does not prove that the buyer received, accepted or approved the invoice.
The visual exchange overview gives the short path. This guide focuses on what to record at each hand-off and how to diagnose a stalled transaction.
A worked hand-off example
Imagine a supplier issuing an invoice against a buyer purchase order. The ERP creates a document with its invoice number and order reference. An integration maps the fields into the buyer's agreed profile and validates the result. A service provider or direct connection sends it to the identified buyer endpoint. The receiving system checks the file, then the accounts-payable workflow matches it to the order.
At least three outcomes need separate labels: the message was delivered to the route; the document passed the recipient's technical checks; and the business accepted or approved it. The precise acknowledgements depend on the channel and recipient.
What should be traceable?
Keep a stable internal transaction key alongside the invoice number, sender and recipient identifiers, output format and profile version, timestamps, message or transport IDs, validation response and any buyer response. This makes it possible to reconcile a rejection with the source record and to avoid accidentally sending a corrected document as a duplicate.
Do not assume that every network sends a business approval message. Define which status your integration can actually observe and how missing responses will be followed up.
Where exchanges fail
Most operational problems are more specific than “the network is down.” A useful runbook separates data errors from addressing, transport and buyer-side processing.
| Failure point | Example signal | Likely owner |
|---|---|---|
| Source data | Missing order reference or incorrect party ID. | Invoice or master-data team. |
| Mapping and rules | Invalid field, code or calculation. | Integration and finance teams. |
| Routing | Unknown recipient endpoint or unsupported profile. | Onboarding or provider team. |
| Transport | Timeout, retry or delivery failure. | Connector or network operator. |
| Business processing | Disputed quantity or unmatched purchase order. | Buyer and supplier operations. |
How should retries and corrections work?
Define whether a failed message is retried with the same identity, replaced with a corrected payload or handled by a formal credit and reissue process. The right answer depends on the error and applicable business rules. Preserve the original response and a link to the corrected attempt. Do not automatically retry a rejected business document indefinitely.
A minimum monitoring view
Operations should be able to filter by partner, date, status, error category and age. Useful measures include documents awaiting acknowledgement, validation rejection rate, time to resolve exceptions and discrepancies between sent and posted counts. Start with a small set of real transactions and test the entire path, including failure cases. The ERP integration checklist covers testing and ownership.
Related guides
- What is electronic invoicing? — How a structured e-invoice differs from a digital document and what happens between sender and recipient.
- Invoice data fields and validation — A practical field map and validation framework for structured invoice implementation.
- ERP integration checklist — A phased checklist for connecting e-invoice data, exchange routes and finance operations.
Primary sources and further reading
These official resources support the standards and regulatory context. Check their current versions before implementation.
- European Commission: What is eInvoicing? ↗ — Definition of a structured eInvoice
- OpenPeppol: Peppol BIS Billing 3.0 ↗ — Billing profile, information elements and validation