How to prepare your ERP for e-invoicing
- min read
- 7 min read
- Published
- Published
- Updated
- Updated
- Written for :
- IT directors, project leads and finance teams ahead of an e-invoicing project.
Short answer
What should we check in our ERP before an e-invoicing project?
Before an e-invoicing project, check that the ERP genuinely holds every piece of data the target format requires — not only what appears on the current PDF — that customer master data contains usable, current identifiers, that the system can receive inbound documents and not only send, and that it can store and report each invoice’s lifecycle statuses. In most cases the ERP already holds the essentials: what is missing is the layer that extracts, formats and handles the responses.
The first question — and it is not "do we need a new ERP?"
Replacing an ERP in order to issue electronic invoices is rarely justified. In most cases the ERP already holds the necessary data; what is missing is the layer that extracts it, puts it in the expected format and handles the responses.
So the right question is: what can the ERP do today, and what gap remains against what the target format requires? That is a measurable gap, not a structural decision.
Check 1 — Data completeness
The classic trap is reasoning from what the current PDF invoice shows. A structured format requires information that appears nowhere on the printed document: standardised identifiers, order references, country codes, tax qualifiers, coded units of measure.
- Legal identifiers for issuer and recipient, in a usable format rather than free text.
- Order and delivery references, where the recipient requires them for matching.
- Tax and unit coding aligned with the expected code lists.
- Structured payment details rather than a sentence in the footer.
Check 2 — Master-data quality
Approximate customer master data produces rejections in series as soon as the recipient identifier becomes a blocking field. What went unnoticed in the era of PDFs sent by email becomes a hard stop.
Consistency across systems matters too: if the ERP, the WMS and accounting disagree on the identifier for the same customer or item, automation will stay partial.
Check 3 — Reception, not only sending
Reception is the most frequently forgotten half. Receiving structured invoices means being able to integrate them, match them to an order and trigger an approval flow.
A project that handles only sending produces an asymmetric result: outbound invoices are automated, inbound ones pile up in a portal nobody opens.
Check 4 — Statuses and traceability
- Can the ERP store a status per invoice (submitted, rejected, accepted, paid) and keep its history?
- Is a rejection visible to the person able to act, or only in a technical log?
- Can a failed flow be replayed without creating a duplicate?
- Is there a record of what was transmitted, exactly as transmitted?
Check 5 — What the project will expose
An e-invoicing project surfaces pre-existing weaknesses that were tolerable while a human reread every document: duplicate customers, items with no stable coding, discounts calculated outside the system, workarounds installed years ago.
Anticipating that avoids discovering it during testing, when the schedule leaves the least room.