Start with the transaction, not the connector
An ERP integration succeeds when the business record, structured invoice, transport response and finance outcome can be reconciled. Before selecting an API or provider, list who creates invoices, how they are approved, which recipients need which formats, and where errors are handled today. A connector cannot repair missing master data or undefined exception ownership.
Phase 1: inventory systems and partners
Map the applications that create, approve, send, receive, post and archive invoices. For each important trading partner, record accepted format, profile, transport channel, participant address, test endpoint and contact for rejections. Separate inbound from outbound flows and public-sector from private-sector customers.
Capture current volumes and the kinds of invoices you actually issue: purchase-order based, services, recurring charges, cross-border transactions, credit notes and corrections. The B2B and B2G guide explains why recipient context matters.
Phase 2: agree the data contract
A field map should show source, meaning, output, transformation, allowed values and owner for each important term. Include tax categories, currency, units, order references, electronic addresses, attachment handling and totals. Validate against the profile and recipient instructions you will actually use.
Decide where the authoritative invoice number is generated and how duplicate detection works. Define whether a change after issuance needs a correction or a new document. The data fields and validation guide has a field-group matrix.
Phase 3: define interfaces and states
Specify how the ERP hands data to the integration, how responses return and what happens during an outage. Record authentication, endpoint ownership, rate or batch behavior, idempotency, retries, log retention and alerting. These are implementation decisions, not universal e-invoicing rules.
| Interface question | Decision to document |
|---|---|
| Initiation | Event, schedule or manual release? |
| Acknowledgement | Which message proves transport, technical acceptance or business outcome? |
| Failure | Who sees it, how quickly, and where is it corrected? |
| Recovery | When is retry safe, and how are duplicates prevented? |
| Change | Who updates profiles, certificates, code lists and partner details? |
Phase 4: test the unhappy paths
A successful sample invoice is necessary but not sufficient. Test missing buyer IDs, invalid tax or total calculations, wrong endpoint, unsupported profile, duplicate number, a rejected document, a timeout and a corrected resubmission. Use representative partners and amounts. Compare the generated structured data to the source and any readable rendering.
Run a controlled end-to-end test to receipt and business processing where the recipient supports it. Keep test evidence and a list of unresolved exceptions before go-live.
Phase 5: prepare operations
Assign owners for validation rules, partner onboarding, incident handling and finance reconciliation. Give staff a view of the document and its status history without exposing unnecessary personal or commercial data. Monitor queue age and repeat rejection patterns. Plan a fallback process that is acceptable to the recipient and jurisdiction, rather than assuming email is always permitted.
A concise go-live gate
Review this gate when a partner, format version, ERP configuration or country rule changes. The exchange flow guide helps define the statuses operations need to see.
- The selected transaction types and recipients are in scope.
- Field mappings and monetary totals have been reconciled against source records.
- Current format/profile and endpoint details have been confirmed with recipients.
- Normal, rejected, duplicate and outage scenarios have named owners and tested responses.
- Monitoring can distinguish delivery from technical acceptance and business approval.
- Local legal, retention and reporting requirements have been checked with qualified advisers where needed.
Related guides
- Invoice data fields and validation — A practical field map and validation framework for structured invoice implementation.
- How an invoice moves between systems — Track the hand-offs, acknowledgements and failure states in a structured invoice exchange.
- B2B and B2G invoicing — Understand how buyer type changes e-invoicing research, obligations and implementation choices.
Primary sources and further reading
These official resources support the standards and regulatory context. Check their current versions before implementation.
- European Commission: eInvoicing implementation checklist ↗ — B2G implementation considerations
- OpenPeppol: Peppol BIS Billing 3.0 ↗ — Billing profile, information elements and validation