E-Invoicing reaches the checkout — why one cloud compliance layer beats every other architecture
An article by Martin Dutzler, E-Invoicing Product Manager at fiskaly
E-invoicing has stopped being a niche accounting topic and become one of the defining compliance waves in European retail. Germany has required businesses to receive structured e-invoices since 2025. France rolls out mandatory B2B e-invoicing and e-reporting across 2026 and 2027. Italy has cleared invoices through the Sistema di Interscambio since 2019. And the EU’s VAT in the Digital Age package sets a hard horizon: digital reporting for cross-border B2B transactions from July 2030, with domestic real-time reporting systems aligned by 2035.
For retailers and POS vendors, the question is no longer whether but where: when a transaction starts at the till, where should the e-invoice be created? A widely held school of thought answers firmly: never at the POS — keep invoicing in the back office, where accounting already lives. The instinct is sound. The conclusion depends entirely on what you imagine the “POS” to be.
The objections — and what they are really about
The case against point-of-sale e-invoicing is familiar: the buyer master data a legal invoice needs lives in the ERP, not at the till. An e-invoice is a lifecycle document — rejections, corrections, archiving — that belongs to finance, not a checkout lane. And with every country running a different model, embedding that logic into till software on thousands of store devices multiplies certification and rollout cost across slow release cycles.
Look closely, though, and every objection targets one specific generation of store technology: the hardware-bound, on-premise POS — large clients with locally installed country logic, fiscal printers, signing devices, firmware updates rolled out store by store. If “e-invoicing at the POS” means burning a second invoicing engine into that stack, the critics are right. But that is an argument against hardware and locally embedded logic — not against issuing the invoice at the moment of sale.
The call for a middle layer is the right call
The same school of thought usually lands on a valuable conclusion: the smartest investment is not a POS-native compliance module but a middle layer between store execution and financial compliance — one that normalizes transaction data, validates it, routes it to the right system and preserves traceability across countries. The decisive question is who operates that layer. Treat it separately and you are shuttling payloads between a fiscalization middleware, an ERP and an e-invoicing platform — immediately you recreate the fragmentation it was meant to solve: three vendors, three data models, three places where VAT logic, rounding and corrections can drift apart. With real-time reporting around the corner the receipt, the invoice and the audit trail must tell the same story!
Cloud fiscalization ends the false choice
Cloud fiscalization has already moved transaction compliance out of the store. Every receipt is signed, sequenced and registered through a real-time API call; offline buffering, country logic, certification and updates all live in the cloud service. Nothing is rolled out at the till. The middle layer is therefore not a future investment — it already exists in production and captures every transaction at origin. Adding e-invoice creation and transmission to that same stream is a marginal step for an integrator, not a second engine. The e-invoice is not created “in the POS” at all: it is triggered from the POS and executed centrally. Central invoice governance and point-of-sale issuance turn out to be the same architecture once the compliance layer is cloud-native.
Worth mentioning is that these structural advantages extend to cloud-native POS platforms as well. While migrating the checkout to the cloud eliminates local hardware rollout friction, it does not resolve the burden of regulatory ownership. A platform backend that attempts to develop its own internal fiscalization and e-invoicing engines merely moves the same administrative challenges to its own data centers: the relentless cycle of multi-country legal monitoring, complex certifications, and the duplication of regulatory updates — all while assuming full compliance liability for domains unrelated to its core commerce function. This always remains as a necessary business decision to make, independent of whether the stack is managed locally or hosted in the cloud.
The structural case for a unified compliance partner
Once fiscalization and e-invoicing are understood as two obligations on one transaction stream, the case for a single provider becomes structural:
- One transaction truth, zero reconciliation. Receipts and invoices derive from the same signed, sequenced stream. Divergence between sales data, fiscal reporting and invoicing is structurally impossible, and corrections propagate to both regulatory areas automatically.
- Regulation is merging the two domains anyway. Croatia fiscalizes the B2B e-invoice itself. B2B cash transactions in Germany over €250 are to be fiscalized and e-invoiced jointly. Spain’s Verifactu records and the e-invoicing mandate describe the same transaction. France feeds B2C e-reporting directly from POS data. Where receipt and invoice become the same legal object, splitting them across two providers means two vendors negotiating one document.
- One integration, one accountable party. A single API covers both obligations: one certification partner, one regulatory monitoring service, one audit trail — instead of coordinating fiscal middleware, an adapter project and an e-invoicing platform for every country rollout.
- Resilience comes built in. Offline queuing, retry logic and sequencing were solved for fiscalization years ago; the same patterns carry e-invoice transmission through outages without blocking a lane.
- The ERP becomes a more precise system of record. Far from being bypassed, the ERP is strengthened. By capturing transaction data at the moment of sale through a unified compliance layer, you feed accounting systems with validated, synchronized, and audit-ready data directly from the source. This eliminates the reconciliation gaps inherent in batch-processed imports, ensuring that the ledger, archive, and receivables accurately reflect the real-time truth of the transaction stream.
Built for what is coming
ViDA’s digital reporting requirements mean transaction-level, near-real-time reporting across the EU. Retailers routing every transaction through a cloud compliance layer today are structurally ready for 2030. Those anchoring e-invoicing exclusively in back-office batch processes will build the real-time POS data pipe later anyway — under deadline pressure, in thirty countries at once.
The conclusion
The true takeaway is not to keep e-invoicing away from the checkout. Rather, it is to decouple regulatory logic from on-premise hardware and local till software, shifting it instead to a unified cloud-native compliance layer — ideally covered by one single provider. This architecture is enabling retailers to focus on their business operations while eliminating the vendor fragmentation that causes reconciliation friction.
This is the architecture fiskaly is built on. As cloud fiscalization solution, fiskaly already processes transactions at the moment of sale through a single API — and extends that same platform to e-invoicing, so that fiscal receipt and legal invoice flow from one stream, one integration and one accountable partner. It is the only approach where compliance gets simpler as regulation gets harder.
