A payables clerk at a mid-market manufacturer approves a €48,000 invoice from a Spanish supplier, schedules it, and releases the payment. The wire settles on time. Two weeks later the supplier's accountant rejects the invoice for tax purposes, because the document arrived as a flat PDF rather than a structured message its national system could recognise. The money moved; the invoice did not. What lands on the finance team's desk is not a payment problem at all — it is a reconciliation and tax-compliance problem wearing a payment problem's clothes.
That scene is becoming ordinary. Over the past several years, governments have pulled invoices out of the private filing cabinet and into regulated infrastructure. An invoice increasingly has to be created in a prescribed format, transmitted through a prescribed channel, and cleared or reported to a tax authority — often before either party can treat it as valid. For companies that buy and sell across borders, this quietly rewrites the wiring between invoices, payments, and reconciliations.
Why e-invoicing is now a payments problem, not just a tax problem
Most AP and AR systems assume one thing: the invoice is the primary key. It is what a payment is matched to, what a dispute hangs off, and what closes the loop between a purchase order and a bank statement. E-invoicing mandates disturb that assumption in three specific ways.
First, validity moves outside your four walls. When an invoice must be cleared or reported to a tax authority, its legal standing depends on a system you do not control. Your ERP can approve a payable on Tuesday while the underlying invoice is still tax-invalid, or was never accepted at all. Payment approval and invoice validity stop being the same event.
Second, payment timing couples to clearance latency. If an invoice cannot be issued until it is registered, or cannot be booked until it is cleared, then treasury's cash forecast inherits a dependency on a government system's response time. That is a new input into working-capital planning, and it does not appear on any payment-run calendar.
Third, reconciliation keys change. When an authority stamps an invoice with its own identifier — an IRN, an SdI transmission ID, a fifty-odd-character fiscal key — that identifier, not your internal document number, becomes the durable reference that survives into audits, disputes, and payments. Teams that reconcile on their own numbering will find themselves unable to prove that a payment settled a specific compliant invoice.
That is why e-invoicing so often falls between the gaps: it is a shared tax, AP/AR, treasury, and IT problem with no obvious single owner.
The mandate models you'll meet across borders
"E-invoicing mandate" is an umbrella term, and the umbrella covers very different machines. Before you design a process, work out which model you are dealing with, because the operational consequences differ sharply.
Clearance models route the invoice through a tax authority or its platform before, at, or shortly after issuance, and return a status or identifier. Italy's Sistema di Interscambio (SdI) is the best-known example: structured invoices flow through the exchange for domestic business transactions, and the platform returns acceptance or rejection. Brazil's Nota Fiscal Eletrônica has worked this way for years, with state tax authorities validating documents and returning authorisation. India's GST system similarly requires affected taxpayers to report invoices to the Invoice Registration Portal and stamp them with an IRN and QR code. The theme across all three: you cannot simply "send a PDF," and the authority's response is part of your process.
Reporting models allow the invoice to be issued between the parties but require the structured data to be reported to the tax administration, sometimes near-real-time and sometimes periodically. The EU's VAT in the Digital Age (ViDA) package points much of Europe in this direction, with digital reporting requirements intended to replace or supplement today's recapitulative statements. Because ViDA is phased and includes options for member states to move earlier, its practical effect on any given company depends on where it is registered and when the relevant provisions apply.
Network and interoperability models rely on a shared standard and accredited access points rather than a single central authority. PEPPOL is the clearest example: buyers and sellers exchange structured business documents over an interoperable network, using common formats both sides' systems can read. It is well established in public procurement and increasingly used in commercial B2B.
Portal and hybrid models mix central platforms with market-specific rules, and are common where a government wants to phase in coverage or serve smaller taxpayers without forcing a full system build.
| Model | What it requires | What breaks in payments |
|---|---|---|
| Clearance e.g. Italy SdI, Brazil NF-e, India IRP |
Structured invoice routed through the authority; acceptance or ID returned. | Payment can be approved before the invoice is tax-valid. Rejections arrive after the payable is booked. |
| Reporting e.g. EU ViDA direction |
Invoice issued between parties, structured data reported to tax administration. | Reporting deadlines sit outside the payment run; data quality failures surface late. |
| Network / interoperable e.g. PEPPOL |
Exchange over accredited access points using common structured formats. | Counterparties not on the network force fallbacks to e-mail and PDF, breaking automation. |
| Portal / hybrid | Central platform plus market rules, often phased by taxpayer size. | Coverage thresholds change; small suppliers drag manual processes along. |
Treat every example above as a starting point. Scope, thresholds, and timelines are revised frequently — confirm the current position with the relevant tax authority or EU source before you build around a date.
What a mandate actually changes in the payment-to-invoice chain
Strip away the jurisdiction-by-jurisdiction detail and one structural change remains: the invoice stops being a document your systems own end to end, and becomes a record that must synchronise with an external authority. That changes both sides of the desk.
On the payables side, the sequence becomes: receive a structured invoice, record its authority identifier, validate it against the purchase order and goods receipt, confirm tax validity, then release payment. The three-way match that most AP teams already run gains a fourth gate — call it tax-validity — that can fail after the business match has succeeded.
On the receivables side, it is the mirror image. You issue or register the invoice, capture the clearance status and identifier, deliver it in the format your buyer's systems can consume, and then need to reconcile incoming cash against a cleared invoice rather than an internal draft. If your reconciliation logic keys on your own numbering, incoming payments with the authority identifier in the remittance field will not match cleanly.
This is where the plumbing between your ERP and your payment platform stops being a back-office nicety. Structured invoices only pay off if the identifier, the amounts, and the status flow between systems without re-keying — which is precisely the case for a well-built ERP and accounting integration. A mandate that produces beautiful structured invoices, which a clerk then retypes into a legacy ledger, has automated the tax filing and nothing else.
Where cross-border payments collide with e-invoicing rules
Domestic mandates are hard enough. Cross-border trade makes them harder, because the payer and the payee can be governed by two different regimes, and neither side's system is obliged to speak the other's language.
Three collisions recur. The first is an issuance-recipient mismatch: a structured invoice from your compliant system may reach a supplier whose regime expects a different format or network, or a supplier's compliant document may arrive at your AP desk as a PDF that your tax authority will not accept for input-VAT purposes. The second is a reporting-asymmetry problem: the supplier's country may require issuance through its platform while your country requires reporting of the purchase, so the same transaction generates two different compliance obligations and two different reference numbers.
The third is the one finance teams underestimate most: a payment rail does not carry invoice validity. A perfectly executed cross-border transfer can settle while the invoice it is meant to pay is non-compliant, rejected, or not yet recognised. And the tax treatment that determines the net amount owed — VAT, GST, and any withholding — is governed by the underlying supply, not by whether the invoice cleared. This is why e-invoicing discussions keep colliding with cross-border tax, VAT, GST, and withholding decisions; the invoice format and the tax outcome are related but not interchangeable.
The practical consequence is that "approved for payment" needs to mean two things: the business approved it, and the invoice is tax-valid. Collapse those into one status and you will eventually pay against a rejected invoice — or freeze a compliant one while chasing a mismatch that only exists because the reference numbers differ.
Where e-invoicing meets ISO 20022 and payment status
There is one genuinely encouraging development in all of this: the same period that pushed invoices toward structured data also pushed payments toward richer, structured remittance information.
ISO 20022, now the backbone of high-value cross-border payments and the SWIFT community's messaging standard, carries far more structured data than the legacy messages it replaces — including room to attach an invoice reference. That means the authority identifier that e-invoicing produced can, in principle, travel with the payment itself, rather than being reconstructed by hand weeks later. If you are still weighing the migration of that messaging layer, our SWIFT GPI and ISO 20022 guide covers what the change means operationally.
The catch is that you then have two status tracks to reconcile, not one. There is invoice status (issued, cleared, rejected, but the money hasn't moved) and payment status (initiated, in transit, settled, but the invoice question is still open). The teams that handle this well keep the two tracks visible and join them on a shared identifier — which is a much smaller step if you have already invested in B2B payment reconciliation automation that matches on structured references rather than on amounts and dates alone.
A practical implementation checklist for AP and AR
You do not need to solve every jurisdiction at once. You need a repeatable method that absorbs the next mandate as easily as the last one. In practice that looks like this:
- Inventory where you actually buy and sell. List your counterparties by country and by rough volume. Mandates usually attach to where a party is established, not where the money lands, so your counterparty map — not your bank-account map — is the right starting point.
- Identify the governing model for each pair. For each significant trading relationship, note whether the model is clearance, reporting, network, or hybrid, and who bears the obligation — issuer, recipient, or both.
- Get authority identifiers into your systems. Decide where the IRN, SdI ID, fiscal key, or PEPPOL identifier will live in your ERP and payment platform, and make it a required field, not a note in a PDF.
- Add tax-validity as a gate in the payment workflow. Extend the three-way match so an invoice that has not cleared cannot reach the release step, and design the exception route for invoices that clear late.
- Choose your access route deliberately. An ERP add-on, a network access point, a specialist service provider, or a direct authority portal integration each carry different cost, control, and maintenance profiles. Pick one route per regime and standardise on it rather than improvising per invoice.
- Re-wire reconciliation to the new keys. Make sure matching logic accepts the authority identifier and the structured remittance reference, so cash posted from a payment carrying an ISO 20022 reference lands against the right cleared invoice.
- Design for rejection. Rejections and late clearances will happen. Define who is notified, within what window, and how a partially approved invoice is reversed, so a rejection does not silently become an unapplied payment.
- Keep an evidence pack per transaction. Store the structured invoice, the clearance response, and the payment reference together. That bundle is what makes an audit conversation short and a dispute resolvable.
Staying compliant when the rules keep moving
The hardest part of e-invoicing is not any single mandate. It is the fact that the rules are living things: coverage thresholds widen, timelines slip, early adopters move ahead of the EU-wide schedule, and a country you do nothing with today becomes relevant when a key supplier relocates there. A process designed around one date is fragile; a process designed around a method survives the next revision.
Two governance habits do most of the work. Keep a single owner — usually a joint responsibility between tax and AP/AR — who reviews mandate changes on a fixed cadence and, critically, re-checks the dates rather than trusting last quarter's summary. And keep the technical plumbing boring: when the invoice identifier, the clearance status, and the payment reference all flow through the same integration, absorbing a new jurisdiction is a configuration exercise, not a rebuild.
Questions we hear most
Does an e-invoicing mandate apply to cross-border transactions, or only domestic ones?
It varies by regime and often by direction. Many clearance systems originally targeted domestic B2B flows and have since extended their reach. The reliable answer is regime-specific — check both the supplier's and the buyer's country, because both may attach obligations to the same transaction.
Can we keep using PDF invoices if both sides agree?
Increasingly, no — at least not for the parties a mandate covers. A PDF is an image of an invoice; mandates generally require structured data that a system can validate. Agreement between two companies does not override a tax authority's format requirement.
If the payment settled, are we compliant?
Payment settlement and invoice compliance are separate facts. Money can arrive against a rejected or unregistered invoice, and an invoice can be perfectly compliant while the payment is still in transit. Track the two independently and join them on a shared identifier.
The practical takeaway
E-invoicing mandates are often filed under "tax project," which is why they surprise payment teams. But an invoice is the key that connects a purchase order, a payment, and a bank statement — and once that key is regulated, the payment and reconciliation chain inherits the regulation. The teams that come out ahead are not the ones that memorise the most deadlines. They are the ones that store the authority identifier as a first-class field, add tax validity as a gate in the payment workflow, and reconcile on structured references instead of amounts. Do those three things, re-check the rules on a schedule, and each new mandate becomes a configuration change rather than a crisis.