Organisations approaching electronic invoicing for the first time usually scope it as a document exercise: produce the invoice in the required structure, send it, done. The structure is the easy part. Everything that makes the integration hard sits either side of it.
Signing is security-critical work
Cryptographic signing is not a library call added at the end of the pipeline. It involves credential storage, token lifecycle, key handling and a clear understanding of what happens when any of those expire or fail mid-process. Teams that treat this as configuration rather than engineering discover the gap at the worst moment — usually when a token expires and nobody owns the renewal.
The response is asynchronous, and that changes everything
A submitted document is not a completed document. Acknowledgements and rejections arrive later, sometimes considerably later, and by then the business has moved on. This means the integration needs durable state: every document tracked from preparation through submission to final resolution, with anything unresolved surfacing where somebody will see it.
- Prepared but not submitted
- Submitted and awaiting response
- Accepted
- Rejected, with the reason preserved
- Failed in transit and requiring retry
If those states are not modelled explicitly, documents go missing quietly. Not many — just enough to create a reconciliation problem at the end of the period.
The business record and the submitted record must not diverge
The most damaging pattern we see is re-entry: the invoice exists in the accounting system, and a separate process re-creates it for submission. The two records then drift. Sometimes it is a rounding difference, sometimes a corrected line that never propagated. Either way the organisation now has two versions of a legally significant document.
The submitted document should be generated from the business record, and the resolution should be written back to it. There should be exactly one source of truth, and it should be the one the business already uses.
Specifications change
Regulatory integrations are not built once. Requirements are revised, fields are added, validation tightens. An integration written as a tightly-coupled special case has to be rewritten each time; one written with the mapping and validation as maintainable, testable components does not.
The practical advice is simple: budget for the exceptions, not the happy path. The happy path takes a fraction of the effort. Everything else is where the work is — and where compliance actually lives.