E-Invoicing and Government Portal Integration

The biggest structural change in ERP over the last decade: tax authorities are now a real-time participant in your invoicing process.

The two models

Post-audit (the old world)

You issue an invoice → send it to the customer → file a periodic return
→ the tax authority may audit you years later

Clearance (the new world)

You create an invoice → submit it to the government platform
→ they validate and assign an identifier
→ ONLY THEN is it a legal invoice you may send to the customer

Clearance changes the ERP fundamentally: an external system with its own uptime is now in your critical path.

Country landscape

Country	System	Model	Notes
Brazil	NF-e, NFS-e, CT-e	Clearance	The pioneer (2006). Goods cannot legally move without an authorised NF-e
Mexico	CFDI	Clearance via PACs	Certified providers stamp invoices
Chile, Peru, Colombia, Argentina	Various	Clearance	LatAm is the most mature region
Italy	SdI	Clearance	All domestic B2B and B2C since 2019
India	IRP + e-way bill	Clearance	IRN + QR code; e-way bill for goods movement
Saudi Arabia	ZATCA Fatoora	Phased clearance	Cryptographic stamps, QR codes
Turkey	e-Fatura / e-Arşiv	Clearance
Poland	KSeF	Clearance
Hungary	RTIR	Real-time reporting	Report within 24h, no clearance
Spain	SII / Verifactu	Near-real-time reporting
France	Facturation électronique	Clearance via PDPs	Phased rollout
Germany	E-Rechnung	B2B mandate phasing in
EU	ViDA	Digital Reporting Requirements	Rolling out through the late 2020s
Bangladesh	NBR Mushak / e-invoicing initiatives	Evolving	Check current NBR circulars

This list changes constantly. Assume any country you operate in will mandate something within five years.

What the ERP must do

Generate the invoice in the mandated format (usually a specific XML schema)
Digitally sign it (certificate management, HSM in some countries)
Submit to the platform (API, sometimes with mTLS)
Receive and store the clearance response: IRN, UUID, authorisation code, QR
Print/send the invoice WITH the government identifier and QR code
Handle rejection: fix and resubmit
Handle cancellation within the permitted window
Reconcile: every posted invoice has a cleared status
Archive in the mandated format for the mandated period

The critical design decision

Never make invoice posting depend on the government API succeeding.

❌ WRONG
   User clicks "post invoice"
     → call the government API synchronously
     → API is down / slow / rate-limited
     → posting fails
     → the business cannot invoice

✅ RIGHT
   User clicks "post invoice"
     → post to the ledger, status = PENDING_CLEARANCE
     → enqueue for submission
     → async worker submits, retries with backoff
     → on success: store the IRN/UUID/QR, status = CLEARED, release for printing
     → on rejection: status = REJECTED, route to a worklist
     → monitor and alert on the pending queue depth

The invoice exists in your books immediately. Only sending it to the customer waits for clearance. This is the difference between a tax portal outage being an inconvenience and being a business stoppage.

The status machine

DRAFT
  ▼
POSTED (in your ledger)
  ▼
QUEUED_FOR_CLEARANCE
  ▼
SUBMITTED ──────────┐
  ▼                 ▼
CLEARED         REJECTED ──▶ CORRECTED ──▶ (resubmit)
  ▼                 
SENT_TO_CUSTOMER
  ▼
CANCELLED (within the permitted window)
  or
CREDIT_NOTED (after the window)

The cancellation window is a hard constraint. India allows 24 hours; Italy, Saudi Arabia, and others have their own limits. After it, the only correction is a credit note referencing the original’s clearance identifier. Users must understand this — “just delete the invoice” stops being possible.

Technical requirements

Digital signatures

Most clearance regimes require a cryptographic signature:

XAdES / CAdES / PAdES signature standards
Certificate management: issuance, storage, renewal, revocation
HSM or secure key storage — a private key in application config is a compliance failure
Certificate expiry monitoring — an expired signing certificate stops all invoicing. Alert 60 days ahead.

QR codes

Increasingly mandatory on the printed/PDF invoice, encoding seller VAT number, timestamp, total, tax amount, and a hash. Format is country-specific (Saudi Arabia uses TLV base64; India encodes a signed JWT). Must be scannable — test with a real phone, not just a decoder library.

Schema validation

Every country has its own XSD or JSON schema with country-specific business rules. Validate locally before submitting — a round trip to get “field 47 is mandatory” is slow and rate-limited.

Rate limits

Government platforms throttle. At month-end you may need to submit 40,000 invoices. Design for: a queue, controlled concurrency, backoff on 429, and a completion estimate you can show the business.

Build vs buy

Option	When
The ERP vendor’s localisation	If they support your countries. Usually the best choice
A specialist provider (Sovos, Avalara, Pagero, Basware, Comarch, EDICOM, local PACs/PDPs)	Multi-country, or where the ERP lacks support
Build it yourself	One country, stable rules, strong in-house capability. Rarely the right call

Strongly favour buy for multi-country. Each country is a moving target with schema changes, rule changes, and platform migrations. A specialist absorbs that; you absorb an ongoing maintenance commitment.

Other government integrations

E-invoicing is the most visible, but the same patterns apply to:

Integration	Purpose
Customs declarations	Import/export filing, duty calculation
E-way bill / transport permits	India, and others — goods cannot move without one
Excise / bonded warehouse reporting	Real-time stock reporting to customs (critical in Bangladesh RMG)
VAT/GST returns	Periodic filing, increasingly via API
SAF-T	A prescribed full-ledger XML dump — Portugal, Poland, Norway, Lithuania, Romania
Statistical reporting	Intrastat, central bank returns
Payroll filings	UK RTI (per payment date), social security returns
Sanctions screening	Denied party list checks
Product registration	Pharma serialisation (EU FMD, US DSCSA)

They share the same characteristics: mandatory, schema-strict, deadline-driven, and operated by a platform with unpredictable availability.

Compliance monitoring

Reports the business needs:

Invoices posted but not submitted        (queue backlog)
Invoices submitted but not cleared       (pending, with age)
Invoices rejected                        (with reason, and an owner)
Clearance response time trend            (is the platform degrading?)
Invoices approaching the cancellation deadline
Certificate expiry countdown
Reconciliation: posted invoices = cleared invoices, for the period

That last reconciliation is the compliance-critical one. A gap between what you booked and what the government has means either unreported revenue or duplicate reporting. Run it daily, not monthly.

Operational realities

Government platforms have outages, often at month-end when everyone submits. Queue and retry.
Rules change with short notice — sometimes weeks. Subscribe to the authority’s notifications, and keep the schema versioned and swappable.
Testing environments are often poor — unstable, non-representative, or unavailable. Build local validation so you’re not dependent on their sandbox.
Penalties are real — per-invoice fines, and in clearance regimes an uncleared invoice may simply not be legally valid, so the customer can refuse to pay.
Time zones matter — deadlines are in local time, and a “24 hour” window means 24 hours from their timestamp, not yours.