ERP e-invoicing process and exception-handling guide
Trace one invoice from source records to provider responses before expanding the integration scope.
Reviewed 26 October 2026. The steps below are a preparation and testing workflow; agree the implementation and exact responsibilities with your contracted provider.
Identify the business scenario and source fields.
Transform to the agreed interface and check the selected profile.
Capture errors and assign a correction owner.
Record the provider document reference and delivery state.
Distinguish exchange status from tax-reporting status.
Retest corrections and preserve the audit trail.
Keep three workstreams separate
Business and tax: decide the applicable scenario and tax treatment with the responsible team. Data: identify the correct source and resolve missing or inconsistent values. Technology: implement mappings, submission, response handling and reconciliation. A completed business questionnaire does not demonstrate that an integration works.
Build a scenario register
Start with normal sales invoices and credit notes. Ask which other scenarios actually occur: prepayments and final settlement, recurring services, document-level allowances/charges, foreign currency, self-billing and supporting references. For each applicable case, record an example, the approval owner, expected totals and the current rule reference. Do not assume that every business uses every scenario.
Plan exceptions before sending
- Missing master data: correct the verified source record and re-export.
- Calculation discrepancy: trace amounts through the ERP and agreed rounding rules.
- Validation rejection: save the specific error and identify the mapping or source-data owner.
- Timeout or uncertain response: check the provider’s status and idempotency procedure before retrying.
- Correction after issue: agree the correct document workflow; do not silently overwrite issued document history.
What evidence should a pilot retain?
Keep the approved scenario, source reference, submitted document identifier, rule/profile version, provider response, correction history and final disposition. Include successful and unsuccessful cases. Synthetic fixtures should be labelled as test data and should contain no real customer identifiers.
Does a successful API response prove completion?
Do not equate transport acceptance with the full business outcome. Confirm what each status means in the provider contract, and which exchange and reporting events your team must reconcile.
Sources: current public guidance and published ERP billing specification. Check current versions before implementation.
Master-data cleanup guide · Free preparation tools · Discuss your workflow
Get InvoiceNext tool updates
Occasional practical tools and source-linked preparation guides. Free tools remain available without subscribing.