The problem in one sentence
Your ERP creates invoices that people read. E-invoicing mandates need invoices that machines read, in a specific format, sent through a specific channel, with responses stored. Integration bridges that gap.
Three ways to comply
| Option | How it works | Best for | Watch out for |
|---|---|---|---|
| Native ERP module | Vendor add-on generates and sends e-invoices from inside the ERP | Current ERP versions with an official module for your country | Version upgrades, limited support for customisations, provider lock-in |
| Middleware connector | A separate service reads from the ERP, transforms, validates and submits | Any ERP, older or customised systems, multiple ERPs or countries | Needs an engineering build and monitoring |
| Provider portal / upload | Staff key in or upload invoices to a web portal | Very low volume | Manual effort, errors, weak audit trail |
Most mid-sized businesses we see end up with a connector, often because their ERP version or customisations aren’t covered by a native module, or because they operate in more than one country.
Reference architecture for an e-invoicing connector
A robust connector has five layers. Keeping them separate is what makes it maintainable.
1. Extraction layer. Reads posted invoices, credit notes and debit notes from the ERP. Options, in order of preference: official API or service layer, event or webhook, database views, scheduled export files. It never changes amounts or accounting entries.
2. Canonical invoice model. A neutral internal representation of an invoice, independent of both the ERP and the country. This is the key design decision. It lets you add a second ERP or a second country without starting over.
3. Country module. Maps the canonical invoice to the mandated format (PINT AE, ZATCA UBL 2.1, MyInvois, XRechnung, eTIMS and so on), applies code lists, runs validation rules, and handles signing, hashing and QR codes where required.
4. Transmission adapter. Talks to the specific ASP, Access Point or tax authority API: authentication, submission, polling or webhooks, retries and idempotency. Swapping provider means swapping this adapter.
5. Status and monitoring. Writes results back to the ERP (status, IDs, QR, errors), keeps the archive, and drives dashboards and alerts.
Step-by-step: how an integration project runs
1. Readiness assessment
List every invoicing source, invoice type and volume. Confirm which mandate and phase applies to each legal entity. Identify the transmission partner.
2. Field gap analysis
Take every mandatory and conditional field in the target specification and find where it lives in your ERP. Typical gaps:
- Buyer tax registration numbers missing or unvalidated.
- Addresses stored as free text, where structured fields are required.
- Tax codes that don’t map one-to-one to the authority’s categories.
- Item descriptions or units of measure that don’t match code lists.
- Credit notes without a reference to the original invoice.
Each gap gets a decision: fix in ERP master data, derive in the connector, or add a field.
3. Build
Build extraction, the canonical model, the country module and the adapter. Add pre-validation so errors are caught before the authority or provider sees them.
4. Sandbox testing
Test with real invoice samples covering every scenario: standard, simplified, zero-rated, exempt, reverse charge, exports, discounts, foreign currency, credit and debit notes. Test failure cases too: API timeouts, rejections and duplicate submissions.
5. Go-live
Switch on per entity or branch, with a rollback plan. Watch the first billing cycles closely, and have an engineer available.
6. Monitor and maintain
Track rejections, keep certificates and credentials current, and apply specification updates.
Data mapping in practice: an example
Field mapping sounds abstract until you see it. Here is a simplified excerpt of the kind of mapping table we agree with a finance team before building:
| Target field (example) | Where it comes from in the ERP | Rule or transformation |
|---|---|---|
| Seller tax registration number | Company settings | Fixed per legal entity |
| Buyer tax registration number | Customer master record | Mandatory for B2B; block posting if missing |
| Invoice type | Document type + customer type | Standard or simplified; credit and debit notes mapped separately |
| Tax category code | ERP tax code | Lookup table: each ERP tax code maps to exactly one authority category |
| Exemption reason | ERP tax code + note field | Required for zero-rated and exempt lines |
| Line net amount | Quantity × unit price − discount | Rounded per specification; totals recalculated and compared |
| Original invoice reference | Credit note “applied to” field | Mandatory on credit notes; flagged if empty |
Every row has an owner. Finance decides tax treatments. The integration team decides transformations. Where data is missing, someone decides whether to fix it at source or derive it. Agreeing this table early prevents most rejections later.
Security and access
A connector touches financial data, so treat it like any other finance system:
- Least privilege. A dedicated integration user in the ERP with access only to the documents and fields involved.
- Secrets management. Provider API keys, certificates and private keys stored in a secrets vault or encrypted store, never in code or spreadsheets.
- Encrypted transport. TLS for every connection, including internal ones where possible.
- Audit trail. Every submission, response and resubmission logged with timestamps and user actions.
- Data residency. Know where the connector runs and where archives are stored, and align it with your policies and any national rules.
Integration routes for common ERPs
- SAP Business One: Service Layer or DI API, user-defined fields for status.
- Microsoft Dynamics 365: Business Central APIs or extensions; Finance and Operations data entities.
- Oracle NetSuite: SuiteTalk, RESTlets and SuiteScript triggers.
- Odoo and ERPNext: a custom module or app, or an external connector over the API.
- Zoho Books, QuickBooks Online, Xero: REST APIs and webhooks.
- Tally: XML over HTTP interface, with TDL customisation if needed.
- Custom PHP, .NET or Java: database views or a small API endpoint added to the app.
More detail on each is on our ERP integrations page.
Project checklist
- All invoicing systems and entities listed, with mandate and phase per entity.
- Transmission partner chosen and sandbox access obtained.
- Sample invoices collected for every scenario.
- Field gap analysis completed and signed off by finance.
- Master data clean-up plan in place (tax IDs, addresses, item codes).
- Connector architecture agreed: canonical model and provider adapter separated.
- Error handling owner and process defined.
- Test plan including failure cases.
- Go-live plan with rollback and hypercare.
- Maintenance plan for specification updates and certificate renewals.
Mistakes we see repeatedly
- Starting with the provider API instead of the data. Data gaps cause most delays.
- Hard-coding country rules into the ERP. It makes every update an ERP change.
- No idempotency. Retries create duplicate invoices with the authority.
- No visible status for finance. Rejections pile up unseen until month end.
- Treating go-live as the finish line. Mandates evolve; integrations need maintenance.
When should you replace the ERP instead?
Rarely because of e-invoicing alone. Consider it if the system cannot store mandatory data and cannot be extended, if it is unsupported and insecure, or if it is already holding the business back for other reasons. Even then, a connector can keep you compliant while you plan a phased legacy software modernization.
How Co-Mate helps
We build e-invoicing connectors for any ERP and any country, ASP-agnostic and maintainable. Start with our ERP integrations page or take the free readiness check.