POS providers in Europe face two compliance mandates at once. Fiscalization is familiar ground: country after country now requires tamper-proof signing of every transaction at the register. E-invoicing is arriving fast. Italy has required structured invoices since 2019, Belgium, France and Poland followed in 2026, and Germany and Spain come next in 2027.
Faced with two mandates, most providers build two integrations. Fiscalization stays in the POS, while e-invoicing moves to the back office, cut off from the checkout where the sale happened.
That works on paper. In practice, one sale ends up in two databases, with two audit trails that may not match and, in the worst case, the same VAT owed twice.
Here's how it works when both run through the POS instead, with one API, one vendor and one audit trail.
What actually happens when the invoice lives in a second system?
"Disconnected" rarely means pen and paper anymore. Usually the e-invoicing tool is connected to the ERP, the accounting suite or a middleware layer in between. Each transaction is exported, synced or re-entered, and on a slide, that looks like a solved problem.
In reality, several systems now share the job of recording a single sale, and every handoff between them is a place where the truth can fork.
Let's follow one B2B sale through that chain:
- The sale starts in the POS. Line items, VAT rates, payment and fiscal signature are captured at the counter. This is the legally binding record.
- The data leaves the POS. It moves by nightly export, middleware sync or CSV import, or someone retypes it from a receipt. At each step, VAT codes, rounding rules, article groups and discounts are mapped onto another system's model. Each mapping is a translation, not a copy.
- The invoice is recreated. The second system creates the e-invoice from the data it received, not from the sale itself. If a line is dropped, a tax code is re-mapped or a discount is applied in a different order, the invoice no longer matches the fiscal record.
- Corrections pull the systems apart. Suppose a sale is voided in the POS after the sync has run, or an invoice is credited in the ERP without touching the POS. The two systems now disagree for good about what was sold, and nothing in this setup brings them back in line.
- The auditor sees two versions. The fiscal journal records one version of the sale, and the invoice archive records another. Reconciling them transaction by transaction, across retention periods of up to ten years, falls to the merchant. They usually find out at the worst possible moment: during the audit.
There is a sharper consequence than mismatched records: the same sale, taxed twice.
In EU VAT systems, tax shown on an issued document is generally owed to the tax office. When the POS issues a receipt showing VAT and a second system later issues a full invoice for the same sale, without the two being linked as one supply, the merchant risks owing that VAT twice until the duplicate is detected and corrected. Germany spells this out in § 14c UStG: incorrectly or additionally shown VAT is owed, full stop. What begins as a workflow gap ends as a tax liability.
None of this is an edge case. It's the everyday reality of the two-system setup, and every back-office e-invoicing tool is built around it.
Why the invoice belongs where the sale happens
The integrated alternative is simple. The same cloud layer that signs the transaction for fiscalization also issues the e-invoice, using the live transaction data at the moment of sale.
Three everyday scenes show the difference:
The business dinner. A guest pays for a team dinner well above the simplified-invoice threshold.
- Integrated: The e-invoice is issued at the table or reaches the guest's inbox seconds later. It's built from the signed transaction and linked to the receipt, so the expense deduction is secured from day one.
- Disconnected: Weeks later, the guest emails to ask for an invoice. Someone rebuilds the dinner in the accounting tool from a photo of the receipt. The restaurant has now issued two documents showing VAT for one meal. If they aren't linked as one supply, the restaurant may owe that VAT twice. This is a tax risk, not just a service problem.
The trade counter. A trade buyer gives a VAT ID at a retail checkout.
- Integrated: The checkout that prints the receipt also issues the e-invoice, and the buyer's accounts-payable system processes it automatically.
- Disconnected: The sale goes into the ERP with the nightly export. There, a re-mapped tax code and a different rounding rule produce an invoice that no longer matches the fiscal record to the cent. Nobody notices until an auditor compares the two systems.
The hotel check-out. A corporate guest checks out.
- Integrated: The front desk issues the e-invoice for the whole stay on the spot. The tourist next in line just gets a receipt. It's the same flow, with one prompt.
- Disconnected: The property management system syncs the folio to finance overnight. The next morning, finance adjusts the corporate rate, so the invoice that finally goes out no longer matches the front desk's records.
In every case, the data starts in the POS. Moving the invoice to a second system means rebuilding that data somewhere else, and everything that goes wrong when a sync, a mapping or a person rebuilds data instead of reusing it.
Integrated vs. disconnected: the comparison
| Criterion | Integrated (in the POS via cloud) | Disconnected (back-office setup) |
|---|---|---|
| Data accuracy | Invoice built from the live transaction: same line items, same VAT split, one system of record | Translated into another backend system's data model, and translations drift: tax codes, rounding, line structure slowly stop matching the fiscal record |
| Audit trail | Fiscal signature, receipt, and XML invoice linked in one system, archived compliantly | Two audit trails across two databases that must be reconciled transaction by transaction |
| Double-VAT exposure | One linked document chain per sale; receipt and invoice reference the same supply | Receipt plus a later, unlinked invoice for the same sale; VAT shown twice can be owed twice (in Germany: § 14c UStG) until corrected |
| Buyer's VAT deduction | Compliant e-invoice at checkout or seconds later | Buyer chases the invoice for weeks; often it never arrives |
| Staff workload | One prompt at checkout, no second step to remember | Spot the B2B case, capture details on paper, hand off to the back office |
| Real-time reporting readiness | The cloud layer already sits in the transaction path, so reporting is added without touching the POS | Cannot report at transaction time by design; a structural rebuild when reporting arrives |
| Multi-market scaling | One integration abstracts XRechnung, ZUGFeRD, Factur-X, FatturaPA, Peppol, and further regimes | Each country's formats and channels handled separately in every back-office tool |
One API, one vendor: what consolidation saves
Under the hood, fiscalization and e-invoicing solve the same kind of problem. Each takes a transaction, turns it into a legally required format, transmits it and stores it in an audit-proof way for years.
Run them as two separate systems and you duplicate every layer:
- two data models to keep in sync
- two authentication setups and organization structures
- two audit trails to reconcile
- two vendors and support queues to coordinate
- two sets of regulatory changes to track in every country
In the integrated model, e-invoicing runs on what you already have for fiscalization: the same transaction data, authentication, organization structure, tamper-proof journal, archive and support contract. Two mandates, one integration. Adding the second mandate costs far less, and so does adding the next country.
ViDA is coming, and it moves compliance closer to the sale
The strongest reason to get this architecture right is what comes next. The EU's VAT in the Digital Age (ViDA) package makes digital reporting requirements mandatory for cross-border transactions by 2030, with member states layering domestic real-time regimes on top.
The direction is clear: reporting is moving closer to the transaction. A back-office tool that receives data days after the sale can keep up only by shortening its sync, and every sync is another place where the two records can drift apart. When the reporting deadline shrinks, the disconnected setup doesn't need an update. It needs to be rebuilt.
An integrated cloud layer already sits in the transaction flow. It signs the transaction today, and adding a reporting step tomorrow extends that same flow, without touching the POS integration again. This is the same architectural bet that decided the last compliance wave: cloud-based fiscalization displaced hardware precisely because a remote, versioned platform absorbs regulatory change on behalf of every connected register.
Where the disconnected model still holds up
Integrated e-invoicing isn't legally required today, and the disconnected model still makes sense in a few places:
- Small receipts stay simple. Below the simplified-invoice threshold (€250 in Germany), a receipt is enough. But sales above that threshold are exactly the B2B transactions that carry audit and double-VAT risk.
- Deadlines are staged. In several markets, issuing e-invoices from the POS stays optional for a year or two. But building the integration takes time, and providers who start now won't be rushing to build it in the final year.
The disconnected model is legal, but it is expensive in ways the price list doesn't show: reconciliation work, audit friction, double-VAT risk, frustrated buyers, duplicated engineering, and a rebuild once reporting moves closer to the sale ahead of 2030.
Key takeaways
- A single B2B sale at the POS can fall under both fiscalization and e-invoicing, so splitting them across two systems creates two records of one transaction.
- If a receipt and a separate invoice aren't linked as one supply, the same VAT can be owed twice. In Germany, § 14c UStG sets this out.
- Running both mandates through one API shares authentication, the audit trail and the archive, so adding the next country costs less.
- ViDA moves VAT reporting closer to the transaction by 2030. A cloud layer already in the transaction flow can add reporting without a rebuild.
Where fiskaly fits
fiskaly builds cloud-based VAT compliance infrastructure for exactly this situation. Our e-invoicing API fiskaly E-INVOICE runs on the same platform as our fiscalization products, so both mandates share one authentication, one organization structure and one audit trail. EN 16931 formats, Peppol access and compliant archiving are all covered by a single integration.
