#r03 — Fiscalization & Regulation, Market by Market

Scope: what a restaurant POS+CRM must do to be legally sellable in each market, what certification gates exist before licence #1, and what that costs in engineer-months and EUR. Date of research: 2026-08-18. Fiscal law moves quarterly; treat anything older than ~6 months as suspect.

Label key: [verified] = checked this session against a live source. [known] = confident from training data (cutoff ~May 2026). [estimate] = reasoned guess, stated as such.

#0. Bottom line up front

1. Fiscalization is not one problem, it is 17 problems that share no code. The signing algorithm, the export format, the registration API, the receipt layout and the certification authority differ in every country. There is almost no reuse beyond a well-designed internal "fiscal adapter" interface.
2. The gate is not always technical — sometimes it is legal-entity. PT, GR, BE, SK, HU require you (the vendor) to be certified/registered as a software producer, and in practice to have a local legal entity, local tax ID and often a local-language support obligation. That is a company-formation problem, not an engineering problem, and it cannot be AI-accelerated.
3. Two 2026 changes materially reshuffle the map, both in our favour:
   • France restored editor self-certification (LOI n° 2026-103 du 19 février 2026, art. 125, effective 21 Feb 2026) after the 2025 finance law had abolished it. NF525 is again optional. France went from a ~EUR 30k / 9-month gate to a self-attestation. [verified]
   • Spain postponed Verifactu to 1 Jan 2027 (companies) / 1 Jul 2027 (everyone else) via RD-ley 15/2025, ratified 11 Dec 2025. We have a full extra year, and a rare chance to be compliant on day one rather than retrofitting. [verified]
4. The cheapest real markets are CZ, NL, UK, UA. Czechia abolished EET on 1 Jan 2023; the Netherlands and UK never had fiscalization; Ukraine's ПРРО is a plain API with no product certification. Combined entry cost for all four is under 8 eng-months.
5. The most expensive are GR, HU, BE, IT, PT — all require certified hardware or vendor-level certification, and all effectively require a local partner.
6. Do not underestimate the recurring tax. Fiscal rules change every year in every country. Budget ~0.35 FTE per "hard" country per year forever, just to stay legal. At 8 hard countries that is ~3 FTE of pure compliance maintenance with zero product value.
7. Buy, don't build, the signing layer. fiskaly / EFSTA / Fiscal Solutions abstract DE/AT/IT/FR/ES/PT/PL and more behind one HTTP API. fiskaly's DE list price is ~EUR 10/month per register, EUR 15 with the DSFinV-K module [verified, from OMR reviews aggregation — confirm with sales]. At a EUR 59-89/month POS ARPU that is 11-25% of revenue, which is painful but far cheaper than building and maintaining 8 national signing stacks.

#1. Master fiscalization table

#Reading the table

• Zero-gate markets (sell tomorrow, engineering only): CZ, NL, UK, UA, DE, AT, FR (post-Feb-2026), ES-state.
• Vendor-certification markets (cannot sell a single licence until certified): PT, BE, SK, HU, GR, PL (virtual registers), IT (software solution), ES-Basque.
• Hardware-mediated markets (you drive someone else's certified box): IT, RO, HU, PL (if not virtual), GR.

#2. Country deep dives — the parts that actually cost time

#2.1 Germany — the export format is the work, not the signing

• Legal base: §146a AO + KassenSichV + DSFinV-K + GoBD. [known]
• TSE signs every StartTransaction/UpdateTransaction/FinishTransaction. Cloud options: fiskaly SIGN DE, Deutsche Fiskal (D-Trust), EFSTA. Hardware: Swissbit microSD/USB (~EUR 60-130, 5-year certificate life), Epson TSE, Diebold Nixdorf. [known]
• Cloud vs hardware is a product decision with support consequences. Hardware TSE fails offline-gracefully but has a hard 5-year cert expiry and a per-device replacement motion. Cloud TSE needs a local offline queue (transactions may be signed late but must be signed) — build a durable outbox with monotonic ordering.
• DSFinV-K is the real cost. ~20-30 CSV files (bonkopf, bonpos, bonpos_ust, bonpos_preisfindung, bon_referenzen, zahlungsart, tse_transaktionen, cashpointclosing, stamm_*, …) with strict cardinality and a cashpointclosing (Z-Bon / Kassenabschluss) model that most naive POS data models cannot produce retroactively. Design your order/payment schema around DSFinV-K from day 1 or you will rewrite it. Version 2.3 applies to records from 1 Jul 2022. [verified]
• Meldepflicht since 1 Jan 2025: every register must be reported to the Finanzamt via ELSTER; pre-1 Jul 2025 devices by 31 Jul 2025; new ones within 1 month. [verified] Product implication: an in-app "generate ELSTER notification data" screen (serial, TSE ID, acquisition date, location) — small, but customers will ask on day 1.
• Belegausgabepflicht since 1 Jan 2020: a receipt for every cash transaction. Electronic is allowed in a standard format; customer need not accept it. Build QR/e-receipt.
• Kassennachschau (§146b AO): unannounced inspection. The auditor plugs in a stick and expects a DSFinV-K export in minutes, plus a Verfahrensdokumentation (procedure documentation). Ship a templated Verfahrensdokumentation as a product artefact — competitors do, and it converts.
• VAT change 1 Jan 2026 (permanent): all Speisen (in-house, takeaway, delivery, events) → 7%; Getränke stay 19%; milk drinks ≥75% milk and tap water sold to-go may be 7%. Combined offers (buffet, all-inclusive) must be split; the tax authority does not object to allocating 30% of the package price to drinks. [verified] → POS needs a per-item rate matrix keyed on (item, channel, packaged?) plus a package-splitting rule engine. This is not a config field; it is a pricing subsystem.
• Effort: 3.0 eng-months (cloud TSE + DSFinV-K + receipt layout + Z-Bon + offline outbox). Add 1.0 if supporting hardware TSE too.

#2.2 Austria — cheapest "hard-looking" market in Europe

• RKSV since 2016. Per-receipt: AES-256 encrypted cumulative turnover counter, RSA/ECDSA signature via a certified SEE, chained to the previous receipt's signature, encoded as QR (or OCR/link) on the receipt. DEP (Datenerfassungsprotokoll) export in the prescribed JSON/DEP-131 structure. [known]
• Registration of the register + SEE with FinanzOnline; a Startbeleg must be verified with the BMF BMF Belegcheck app; monthly Nullbeleg and a Jahresbeleg on 31 Dec verified by 15 Feb. [known] Automate the Nullbeleg — it is the #1 support ticket in AT.
• No product certification. Use A-Trust a.sign RK online, PrimeSign, or fiskaly SIGN AT.
• AT is DE's cheap sibling: same language, same sales motion, ~1/3 the engineering. Do them together.
• Effort: 1.5-2.5 eng-months with a cloud SEE. 4-6 if you implement the AES chain and DEP yourself (don't).

#2.3 France — the 2026 reversal, and the sleeper that replaces it

• Since 2018, art. 286-I-3° bis CGI requires cash software to guarantee inaltérabilité, sécurisation, conservation, archivage. Proof was either an accredited certificate (NF525 via Infocert, or LNE) or an éditeur self-attestation.
• Loi de finances 2025 abolished self-attestation from 1 Mar 2026; BOFiP then extended the editor-certificate deadline to 31 Aug 2026. Loi de finances 2026 (LOI n° 2026-103 du 19 février 2026), art. 125, restored self-attestation with effect from 21 Feb 2026. Businesses may now supply either an editor attestation or an accredited certificate. [verified]
• What did NOT change: the four technical obligations, the JET (journal des événements — every price change, discount, reprint, training-mode entry, cancellation, parameter change is an immutable event), the mandatory clôtures journalière / mensuelle / annuelle with cumulative and perpetual grand totals, signed archives, and the EUR 7,500 fine per software on the merchant with 60 days to fix. Auditors test the software. A self-attestation you cannot defend is a liability, not a shortcut.
• Strategic call: self-attest for v1 (EUR 0, ~0 elapsed). Get NF525 later only if enterprise/franchise procurement demands it. NF525 ≈ EUR 15-30k first pass + EUR 5-10k/yr surveillance, 4-9 months elapsed [estimate].
• Sleeper: B2B e-invoicing + B2C e-reporting. Reception obligation for all businesses from 1 Sept 2026; issuance for large/ETI 1 Sept 2026, SMEs/micro 1 Sept 2027; routed via PDP (Plateformes de Dématérialisation Partenaires) after the PPF was reduced to a directory/concentrator role. [known — verify current calendar] For a restaurant this means: (a) receive supplier invoices electronically, (b) e-report B2C transaction data on the same clock. That B2C leg is an aggregate transmission of daily takings through a PDP — genuinely new POS work, ~1.5-2 eng-months, and it lands right in our window.
• Receipt printing is prohibited by default (loi AGEC, from 1 Aug 2023): tickets de caisse and card slips are only printed on customer request. Default-off printing + e-receipt is a hard requirement in FR, not a nicety. [known]
• Effort: 2.5 eng-months (JET + clôtures + archives + self-attestation dossier + no-print default) + 2.0 for PDP/e-reporting.

#2.4 Italy — the 2026 POS-linkage trap

• Corrispettivi telematici since 2020. Three legal routes: certified Registratore Telematico hardware; RT Server / soluzione software (AdE-approved software with a "punto di emissione"); or the free Documento Commerciale Online web portal (useless above ~10 receipts/day).
• New from 1 Jan 2026: the payment terminal must be technically linked to the RT (2025 Budget Law). AdE published technical specs on 31 Oct 2025; the registration web service went live in early March 2026 (~5 Mar); merchants have 45 days to register the link. [verified] This makes IT a joint POS+payments problem — you cannot ship a card terminal in Italy that is not RT-aware. Confirm which acquirers (Nexi, SumUp, Stripe Terminal, Mollie) already expose the linkage and which push it back to the POS vendor.
• Lotteria degli scontrini requires capturing the customer's codice lotteria on the documento commerciale. [known]
• Recommendation: do not homologate our own RT. Integrate Epson FP-81 II / RCH / Custom / Ditron over their documented XML/serial protocols, or buy fiskaly SIGN IT (RT-server style). Own homologation is EUR 30-80k and 6-12 months [estimate] for a market we do not need on day one.
• Effort: 2.5-3.5 eng-months to drive one RT family + corrispettivi + POS linkage. Multiply by ~0.6 per additional RT vendor.

#2.5 Spain — a rare "arrive compliant" opportunity

• State regime (RD 1007/2023 + Orden HAC/1177/2024 + RD 254/2025 + RD-ley 15/2025): invoicing software must produce a chained, hashed, signed record per invoice and either send it to AEAT in real time (Verifactu) or keep it locally with a qualified e-signature and a tamper-evident event log (no-Verifactu). Every invoice carries a QR. The producer files a declaración responsable.
• Dates: 1 Jan 2027 for corporate-tax payers, 1 Jul 2027 for everyone else (RD-ley 15/2025, ratified 11 Dec 2025 by 179-168). [verified] Earlier RD 254/2025 dates of 1 Jan 2026 / 1 Jul 2026 are superseded; many Spanish-language blogs still quote them — do not trust them.
• Restaurant nuance: most restaurant sales are B2C "facturas simplificadas". Verifactu applies to simplified invoices too, so every receipt becomes a signed, chained record. Choose Verifactu mode (send-everything) over no-Verifactu — the local-signature mode requires certificate management on-premise and heavier audit evidence.
• Basque Country + Navarra are a separate product. TicketBAI has three provincial flavours with different XSDs, different web services, different registries, plus Navarra's own scheme. Budget them as a fourth "country", not a config flag. [known]
• Effort: 2.5 eng-months for state Verifactu; +2.5-3.5 for TicketBAI (3 provinces) if the Basque market is targeted. Defer Basque.

#2.6 Portugal — the hardest small market in Western Europe

Gate stack, all mandatory:

1. Software producer certification by AT → you receive a certificate number that must be printed on every document ("Processado por programa certificado n.º XXXX/AT"). Requires a Portuguese NIF and, in practice, a local representative. [known]
2. Document signature chain — RSA private key issued to the certified producer, signing a canonical string per document, chained to the prior document in the series.
3. ATCUD — each document series must be registered with AT's webservice to obtain a validation code; ATCUD prints on the document.
4. QR code on every document (mandatory since 1 Jan 2022), with a prescribed field layout.
5. SAF-T (PT) — billing SAF-T; plus SAF-T accounting obligations expanding.

• Nothing here is intellectually hard; all of it is exacting, and the certification is a company-level gate that blocks all revenue in PT until granted.
• Effort: 3.5-5 eng-months engineering + 2-4 months elapsed for certification + local entity setup. Do not attempt PT in year 1 under S1.

#2.7 Poland — two regimes plus KSeF on top

• Fiscal receipts: kasy online (GUM-homologated hardware) with automatic transmission to Centralne Repozytorium Kas. Kasy wirtualne (software) are permitted only for enumerated industries; gastronomy (PKD 56) is on that list [known — verify against the current Rozporządzenie, this is decisive for PL strategy]. A virtual register still needs GUM confirmation that the software meets the technical criteria — a real certification, PLN 50-150k and 6-12 months [estimate].
• KSeF (structured e-invoicing) is now live: mandatory 1 Feb 2026 for taxpayers over PLN 200m 2024 turnover, 1 Apr 2026 for everyone else; receiving via KSeF is mandatory for all from 1 Feb 2026. Micro-issuers (<PLN 10k/month) from 1 Jan 2027. [verified]
• Receipt/invoice interaction: a receipt with NIP up to PLN 450 is a simplified invoice; those are excluded from KSeF from 1 Feb to 31 Dec 2026, and must go into KSeF from 1 Jan 2027. [verified] This is a dated feature requirement with a hard cliff — a Polish restaurant POS must be able to push simplified invoices into KSeF by 1 Jan 2027.
• JPK_V7M with GTU codes and PKWiU classification per item.
• Effort: 2.0 eng-months for KSeF + JPK; plus either 6-12 months/EUR 12-35k for GUM virtual-register certification, or a partner integration with an existing kasa online vendor (Posnet, Elzab, Novitus) at ~1.5 eng-months.

#2.8 Czechia & Slovakia — the split personality

• CZ: no fiscalization. EET was abolished effective 1 Jan 2023 and has not returned. [known] Only VAT records and kontrolní hlášení. Czechia is the single best CEE entry point on a compliance-cost basis.
• SK: eKasa. Every register is an ORP paired with a certified CHDÚ and an eKasa klient identity issued by Finančná správa; the cash register program itself is certified. [known] So a shared "CEE product" does not exist — CZ is free, SK is a 3-6 month certification.
• Effort: CZ 0.25 eng-months (VAT config, receipt content, currency rounding). SK 2.5-3.5 eng-months + certification elapsed.

#2.9 Hungary — hardware-gated, but the door may have opened

• Online pénztárgép with an AEE (SIM-connected tax control unit) reporting to NAV; hospitality (TEÁOR 56) is on the mandatory list. Historically a POS could only be a "front" to a certified NAV device. [known]
• e-nyugta / e-pénztárgép: the 2024 legislation created a software e-cash-register regime with a central NAV e-receipt repository and a consumer "Vevői Alkalmazás". This in principle allows a pure-software register with type approval. [known — verify current state; this is decisive for HU]
• Online Számla 3.0 real-time invoice XML reporting is separate and mandatory.
• VAT trap: 5% on restaurant food + on-site non-alcoholic drinks, but an additional 4% turizmusfejlesztési hozzájárulás on the same base — a second, non-VAT levy the POS must compute and report. [known]
• Effort: 4-6 eng-months + type approval; not a year-1 market.

#2.10 Romania — three parallel obligations

• AMEF fiscal device (certified hardware) with electronic journal; POS drives it over serial/USB. Daily Z, monthly XML to ANAF.
• RO e-Factura — B2B mandatory since Jul 2024, B2C reporting also in scope: Romanian taxpayers must report domestic B2C supplies through e-Factura. [verified] For restaurants this bites whenever a guest requests a factura rather than a bon fiscal, which is very common for business meals — that invoice must go to SPV via e-Factura, signed, within the deadline.
• SAF-T (D406) rollout completes through 2026: large Q1, medium Q2, small/micro Q3, public Q4. [verified] Every restaurant client will need SAF-T-shaped accounting data out of our system.
• VAT: standard raised to 21%, reduced 11% from 1 Aug 2025; HoReCa moved 9% → 11%. [known — verify] Alcohol and sugar-added drinks at standard.
• Effort: 3.0-4.0 eng-months (AMEF driver + e-Factura + SAF-T extract). Local AMEF partner required.

#2.11 Greece — do not enter without a partner

• ΦΗΜ (tax mechanism) type approval, myDATA real-time transmission of all invoices plus daily summaries, mandatory POS-terminal ↔ cash-register interconnection (enforced since 2024 with per-instance fines), an AADE POS registry, and an ERP registration obligation with a declaration of conformity. myDATA is expanding: full e-invoicing coverage from 1 Oct 2026, e-delivery Phase B from 12 Oct 2026, item-level classification from 1 Jan 2027. [verified]
• Highest compliance density in the EU relative to market size. Skip unless a Greek reseller brings the certification and the customers.
• Effort: 5-7 eng-months + AADE registration. Not economic under S1.

#2.12 Netherlands, Belgium — adjacent countries, opposite worlds

• NL: no fiscalization at all. Belastingdienst relies on the general 7-year administratieplicht; the Keurmerk Betrouwbare Afrekensystemen is voluntary and mostly a trust badge. NL is a free market to enter and has high restaurant tech spend. VAT trap: 9% food and non-alcoholic drinks in hospitality, 21% alcohol.
• BE: GKS/SCE + FDM ("blackbox") mandatory for horeca. GKS 2.0 replaces the VAT Signing Card with an FDM 2.0 that talks to the FPS Finance cloud over an API. New businesses from 1 Jan 2026; tolerance period ended 31 Mar 2026; enforcement from Apr 2026; existing SCE 1.0 installations migrate from 1 Jul 2026 with cohort deadlines (2014-2017 → end Jun 2027; 2018-2021 → end Jun 2028; 2022+ → end 2028). As of Mar 2026 only 3 FDM suppliers and 13 certified software suppliers existed for v2. [verified]
• Belgium is a genuine strategic opportunity precisely because the certified field is tiny and a forced migration wave runs 2026-2028. But it costs a certification (6-12 months, EUR 20-50k [estimate]) and BE has a 21% VAT rate on all beverages including soft drinks vs 12% on restaurant food — a per-item, not per-order, rate.

#2.13 Ukraine — cheap, real, and structurally risky

• ПРРО under Law 265/95-ВР. Register the economic unit (form 20-ОПП), the register (1-ПРРО) and cashiers (5-ПРРО); fiscalize each receipt against the ДПС fiscal server; sign with КЕП using ДСТУ 4145-2002 elliptic-curve crypto. [verified]
• The crypto is the work. ДСТУ 4145 is not in OpenSSL. Options: IIT's signature library (commercial, Windows-centric historically), Cryptonite, or libuapki/libcrypto-uapki (open-source, actively used). Key material arrives as .dat/.jks/.pfx files or on hardware tokens; a cloud POS must handle server-side key custody, which raises a legal question about who is the signer.
• Offline mode is mandatory, not optional: pre-issued offline fiscal number ranges, limits (order of 36h per outage / 168h per month [known — verify]), and reconciliation on reconnect. In a country with rolling blackouts this is the single most important feature, and it is also an excellent forcing function for building genuine offline-first POS architecture that pays off everywhere else.
• Excise: 5% retail excise on alcohol must be computed and shown; excise stamp handling for spirits.
• Effort: 3.0-4.0 eng-months (crypto + fiscal server + offline ranges + X/Z + 1-ПРРО/5-ПРРО flows). No certification.

#2.14 UK & US — no fiscalization, different bills to pay

• UK: nothing fiscal. MTD for VAT is an accounting-layer obligation. The binding regulation is employment law (see §5).
• US: nothing fiscal. The equivalent burden is sales tax (see §6) plus PCI (see §7) plus a patchwork of state labour and tipping rules.

#3. What "certification" actually involves (process mechanics)

Founders consistently underestimate this because it is not engineering work. The typical shape, per certifying market:

1. Eligibility — the authority certifies a producer, not a product owner. Reselling someone else's certified engine under our brand is usually not permitted without our own certification (PT, BE, SK explicitly; GR via the ERP registry). Expect to need a local tax ID at minimum, a local legal entity at worst.
2. Dossier — technical description, data model, security architecture, source-code escrow in some regimes, and a formal declaration of conformity signed by a company officer. Typically 40-150 pages. Budget 3-6 weeks of a senior engineer's writing time per country, which no AI shortcut fully removes because it must be defensible under audit.
3. Test campaign — you run the authority's (or an accredited lab's) conformance scenarios and submit evidence. Expect 2-4 round trips. Each round trip is 3-8 weeks of their calendar, not yours. Elapsed time is dominated by queueing, not by work.
4. Version binding — the certificate names a software version. Material changes require re-notification or re-certification (NF525 surveillance audits annually; PT re-certification on structural changes; BE on GKS version bumps). This directly conflicts with continuous deployment. Design a "fiscal core" module that is versioned and released slowly, separate from the fast-moving app. If your fiscal logic ships with every web deploy, you will invalidate your own certificate.
5. Ongoing obligations — many regimes require notifying the authority of every customer installation (BE, SK, HU, GR), which means an operational process, not just an API.

Rule of thumb: elapsed time ≈ 3× engineering time in certifying markets. A 4 eng-month Portugal build is a 9-12 month time-to-first-revenue.

#3.5 Penalties — what your customer is actually afraid of

This is the sales pitch. Quantify it in every deck.

Spain is the outlier that matters: it fines the software producer, not just the user. Any Spanish launch needs a signed legal opinion that our implementation satisfies RD 1007/2023 before the first installation.

#4. VAT / rate traps that break naive POS data models

The universal mistake is storing one VAT rate per product. You need rate = f(product, channel, packaging, temperature, container, on-premise?, customer_type, date).

#Service charges, tips, and receipt content

• Mandatory service charge is revenue in most jurisdictions (VAT-able in UK/IE; wages, not tips, under US FLSA). Discretionary tip is outside the scope of VAT in the UK and most of the EU. If your data model calls both "tip", you will mis-file VAT for every customer. Model gratuity_discretionary and service_charge_mandatory as distinct, non-convertible entities from day 1.
• DE: tips to employees are tax-free for the employee; tips to the business are taxable revenue. The POS must let the operator declare which.
• FR: "service compris" since 1987; a separate service line is atypical and invites disputes.
• Receipt content is prescribed per country and always includes at minimum: merchant name + tax ID, date/time, sequential document number, per-rate VAT breakdown, payment method, and the country-specific fiscal artefacts (DE: TSE serial + signature counter + start/end time; AT: RKSV QR; PT: cert number + ATCUD + QR; ES: Verifactu/TBAI QR; IT: documento commerciale layout; HU/GR: device identifiers). Build the receipt renderer as a per-country template engine with a validation test suite, not as string concatenation. ~1.5 eng-months for the framework + ~2 eng-days per country.
• E-receipts are accepted in DE, AT, IT, FR (FR: preferred), and increasingly elsewhere, but the fiscal artefacts must be present in the electronic form too. HU's e-nyugta requires delivery into the NAV repository plus a consumer app.

#5. Non-fiscal regulation you cannot ship without

#6. US: no fiscalization, but sales tax is a permanent operating obligation

Why it is different from VAT: the rate depends on the destination address at street level and taxability depends on product characteristics that vary by state (heated? utensils provided? sold with seating? soda vs juice? bakery item count?). There are ~13,000 taxing jurisdictions [known].

#Tax engine options (list pricing, all [known] — verify with current rate cards)

Recommendation: for US v1, build a thin rate/taxability service seeded from a commercial rate feed for the specific ZIPs we serve, and integrate Avalara only when a multi-state chain demands filing. Do not put a percentage-of-GMV tax engine in the critical path.

Plus, in the US, the real gate is payments, not tax: PCI DSS 4.0.1 (fully mandatory since 31 Mar 2025 [known]), EMV L1/L2/L3 certification per acquirer if we touch card data, and the strong incentive to stay SAQ-A/P2PE by using a semi-integrated terminal (Stripe Terminal, Adyen, Square) so card data never touches our stack. Design decision: semi-integrated only. Never handle PAN.

#7. Payments regulation adjacency (short, but it kills timelines)

• EU: PSD2 SCA — card-present is largely exempt, but "pay at table" / QR-pay / stored-card CRM flows hit SCA and need 3DS. PSD3/PSR are in the legislative pipeline for ~2026-2027 [known].
• PCI DSS 4.0.1 applies everywhere we exist. Staying out of scope via P2PE-validated or semi-integrated terminals reduces this from a EUR 30-80k/yr QSA problem to a SAQ-A questionnaire. [estimate]
• IT 2026 RT-POS linkage (§2.4) means Italy's payments and fiscal domains are now coupled — a payments decision becomes a fiscal compliance decision.
• GR already couples them (POS-cash register interconnection).
• Trend line: more countries will couple the terminal to the fiscal device. Architect for it: the payment result must be a first-class field on the fiscal transaction, not an afterthought.

#8. Recurring compliance cost (the part everyone forgets)

Entry cost is one-off. This is forever:

A 10-country European footprint carries ~2.5-3.0 FTE of permanent compliance engineering. Under S1 (founder + 2-4 engineers) that is mathematically impossible past ~3-4 countries. This is the single strongest argument in this document for narrow geographic focus.

#9. Recommended market sequencing

Ranked by (revenue opportunity) / (compliance cost). Restaurant counts are [estimate] unless noted; use them as orders of magnitude only.

#Concrete recommendations

• S1 (bootstrapped, 24 months runway): ship CZ + UA first (3.75 eng-months of compliance total), then DE+AT (4.5), then NL (0.5). That is ~9 eng-months of compliance across four countries, ~10-12% of an S1 team's 24-month capacity — survivable. Do not touch PT/GR/HU/BE/SK/IT/US.
• S2 (EUR 5-10M, 15-30 people): DE+AT+NL+CZ in year 1, FR+PL+ES in year 2, IT+BE opportunistically in year 3 with local partners. Budget a dedicated 2-person compliance engineering team from month 6 — not a shared responsibility.
• Never do this: launch in 8 countries "because we're cloud". Each country is a support obligation in a local language with a local auditor who can shut down your customer.

#The strategic argument for buying middleware

At 500 registers, middleware costs ~EUR 60-90k/yr — roughly one senior engineer. Buy until ~2,000 registers, then reassess per country. Keep a clean internal FiscalProvider interface so the swap is possible; never let fiskaly's data model leak into the order model.

#Build effort

Engineer-months for a competent senior engineer with heavy AI assistance. "Variance driver" is what makes the estimate double.

Interpretation: compliance alone is ~22 eng-months for the minimum sensible S1 footprint. Against an S1 team of ~3.5 engineers × 24 months ≈ 84 eng-months of total capacity, compliance consumes ~27% of everything the bootstrapped team will ever build, before a single line of POS UI or CRM logic. That number, not the market size, should drive the go/no-go.

#Open questions / what would change this answer

1. Poland: is gastronomy (PKD 56) still on the permitted "kasy wirtualne" list, and what exactly does GUM require of a virtual register? If software registers are permitted and the GUM process is <6 months / <EUR 15k, Poland jumps from rank 6 to rank 4. Confirm: current Rozporządzenie Ministra Finansów on virtual cash registers + GUM published criteria. This is the single highest-value unknown in the document.
2. Hungary: is the e-pénztárgép (software cash register) regime actually operational with certified vendors, or still theoretical? If operational, HU moves from rank 15 to ~rank 9 and becomes a viable CEE cluster member with CZ/SK/PL. Confirm: NAV's register of approved e-pénztárgép suppliers.
3. France: what is the current B2B e-invoicing / B2C e-reporting calendar after the several postponements? Item 7 (2.0 eng-months) is either urgent for Sept 2026 or deferrable to 2027-2028, which changes the FR entry sequencing by a year. Confirm: impots.gouv.fr / DGFiP calendar and the PDP register.
4. What does fiskaly (or EFSTA / Fiscal Solutions) actually charge for a multi-country bundle at 100 / 1,000 / 5,000 registers, and which of DE/AT/FR/IT/ES/PT/PL/GR/RO do they cover to production quality? The EUR 10-15/register/month DE figure is a public list price; multi-country volume pricing is the number that decides build-vs-buy for items 4-12 (~22 eng-months at stake). Confirm: direct sales quotes from at least two vendors.
5. Does Ukraine's ПРРО regime legally permit server-side custody of the merchant's КЕП key by a SaaS provider? Every Ukrainian cloud POS does it in practice, but the legal basis (and our liability if a key is misused) needs a Ukrainian tax lawyer's opinion. If it does not, the architecture needs client-side signing and the offline story gets much worse.
6. Is a local legal entity strictly required — or only practically required — in PT, BE, GR, SK, HU? The difference between "AT will certify a foreign producer with a PT NIF and fiscal representative" and "AT requires a Portuguese company" is roughly EUR 5k vs EUR 25k and 1 month vs 4 months per country. Confirm: each authority's published certification procedure, plus one local accountant per country.

What would most change the conclusion: if a single middleware vendor genuinely covers DE/AT/FR/IT/ES/PT/PL/BE/GR at a per-register price under ~EUR 8/month, the compliance line item drops from ~22 eng-months to ~9 for the S1 footprint and from ~72 to ~30 for full coverage. That would make a pan-European play feasible even under S1 — and would make "which countries" a pure go-to-market question instead of an engineering-capacity question. This is the first thing to test, before writing any code.