Digital invoicing changes a quiet assumption most finance systems are built on: that an invoice is finished the moment it prints. Under a digital invoicing regime it is not. The document has to be submitted, accepted and carry a verification reference before it is valid, and that has to happen while the customer is still standing at the counter.

That one change is why so many integrations go badly. The problem is rarely the API. It is that the invoice is no longer a document your system owns outright, and very little enterprise software was designed with that in mind.

What the requirement actually is

Stripped of the paperwork, digital invoicing asks three things of your systems. Each sales tax document must be transmitted to the tax authority at the point it is issued. The response must be recorded against that document. And the verification reference returned must appear on the copy the customer takes away.

Everything else — the retry logic, the reconciliation views, the audit trail — exists because those three things have to hold under real conditions: a dropped connection, a queue at the till, a credit note raised three weeks later against an invoice someone has already filed.

Where integrations usually fail

Most failed integrations share a shape. The connection is built as a one-way push, treated as fire and forget, and nobody discovers the gap until a return is being prepared.

Submission treated as optional
If a failed submission leaves the invoice in a valid state, the system has quietly taught everyone to ignore failures. The document must not be considered complete until it has a response.
No retry queue
Connections drop. Without a queue that holds, retries and surfaces failures, a day of invoices can silently fall out of the return.
Reconciliation left to a spreadsheet
If your only way to check what was filed is to export both sides and compare, nobody will do it weekly, and the gaps compound.
Adjustments filed as new documents
A credit note is an adjustment against an original, not an unrelated entry. Filing it as a standalone document breaks the audit chain.
No submission history retained
When a return is questioned a year later, the request and the response for each document are the evidence. Keeping only the final status is not enough.

Inside the ERP, or in front of it

There are two sound ways to do this, and one that causes pain.

The first is to put submission inside the sales module, so the invoice cannot be printed without a response. This is the cleanest option, because the rule is enforced where the document is created rather than bolted on afterwards.

The second is a middleware layer in front of an ERP you cannot modify. The ERP posts the document, the layer handles submission, retries and reconciliation, and writes the reference back. This is the right approach for systems you do not control — an older ERP, a point of sale from a vendor who has not implemented it, or a mix of several.

The approach that causes pain is manual entry on a portal alongside the ERP. It works for a dozen invoices a day and collapses at a hundred, and it guarantees the two records will diverge.

What to ask a vendor

Most of the risk is visible from five questions, and the answers tell you quickly whether a vendor has run this in production or only read the specification.

What happens when submission fails?
You want to hear about a queue, automatic retries and a visible list of pending documents. "It logs an error" is not an answer.
Can an invoice print without a reference?
The answer should be no, or configurable to no. If unsubmitted documents can leave the building, the control is decorative.
How are credit and debit notes handled?
They should be filed against the original document, not as loose entries.
What does month-end reconciliation look like?
There should be a view of every document filed, pending and rejected, with the reason attached — not an export.
How long is submission history kept?
Full request and response per document, retained for the statutory period.

A realistic implementation

For a single company with clean master data, connecting an existing ERP typically runs three to six weeks: credential setup and sandbox testing, mapping your document types and tax rates to the required fields, a parallel run where documents are submitted but the old process continues, then cutover.

The parallel run is the part people try to skip and should not. It is where you discover that your exempt supplies are coded three different ways, or that a branch has been issuing invoices from a spreadsheet nobody mentioned.

Common questions

Does digital invoicing mean we have to replace our ERP?

No. If your ERP cannot be modified, a middleware layer in front of it handles submission, retries and reconciliation, and writes the verification reference back. Replacing a working ERP for this reason alone is rarely justified.

What happens if the connection drops mid-day?

A correctly built integration queues the documents, retries automatically and shows you what is pending. Nothing should be lost, and nothing should print as valid without a response.

Can a point of sale handle this without slowing the counter?

Yes. Submission happens as the invoice is raised and typically completes in well under a second. The queue matters for the exception, not the normal case.

How long does integration take?

Three to six weeks for a single company with clean data, including a parallel run. Multi-company groups and businesses with several document sources take longer.