One Invoicing Stack for Poland, Germany, and Spain
If you sell in Warsaw, Munich, and Valencia, you already have three e-invoice machines. Here is the shared record, the per-market validators, the archive periods, and the transports that should not leak into each other.
One Invoicing Stack for Poland, Germany, and Spain
A shop that invoices a German wholesaler, a Spanish hotel group, and a Polish distributor is not "doing e-invoicing." It is running three legal machines that share a commercial fact: who bought what, for how much, in which currency, payable how.
Put that fact in three unrelated tools and you will reconcile yourself into a fourth. Put it in one record with three adapters.
The Shared Record
Every market needs the same core:
- Seller and buyer legal identity (name, tax ID, address, in Spain also the SIF identity of the software)
- Document type (invoice, credit note, advance, corrective)
- Lines: quantity, net, VAT rate, exemptions, reverse charge
- Totals that arithmetically match the lines
- Currency, FX source and date if not the local tax currency
- Payment means (IBAN, terms, in Poland later the KSeF number in the transfer title)
- Buyer references (PO, BT-10, Leitweg-ID, Spanish administrative references)
- Issue date, tax point, due date
This record is not an EN 16931 file. EN 16931 is a projection. FA(3) is a projection. Facturae is a projection. If you store only the XML you sent to KSeF, you cannot emit XRechnung without a lossy reverse map.
Validators Are Per Market, Not Optional
| Market | Validator | Failures that look like "the invoice sent" |
|---|---|---|
| Poland | KSeF schema + business rules, then the live node | Error codes on session; no KSeF number, no invoice |
| Germany | Schema plus KoSIT / EN 16931 business rules | Empty BT-10, arithmetic mismatch, wrong ZUGFeRD profile. Recipient rejects or parks it. |
| Spain | Facturae / UBL / CII, signature, Verifactu hash and QR if SIF applies | Unsigned PDF, missing QR, platform rejection, missed 4-day status |
Run the validator before the transport. A German send of ZUGFeRD Minimum (not EN 16931) is a successful email of a non-invoice. A Spanish send without a signature is a PDF with ambition.
Transports Must Not Leak
KSeF offline modes are a Polish legal design. They are not a way to "queue German invoices when SMTP fails." German email failure is a channel retry, not an offline clearance. Spanish Verifactu incident mode is a SIF rule with a later catch-up. TicketBAI still assumes connectivity and has no polite offline story.
Configuration sits on the buyer: Poland always KSeF for in-scope VAT invoices; Germany email or Peppol per Peppol ID; Spain the accredited platform the counterparty is on, with interconnection. The operator should not pick a channel from a global dropdown.
Archive Is Not "Keep the PDF"
| Market | What must remain unchanged | Today's working retention |
|---|---|---|
| Poland | FA(3) and the UPO, signature intact | 10 years (KSeF session history is not your only copy) |
| Germany | The structured record (XML, or PDF/A-3 with embedded XML). Flattening a ZUGFeRD to a plain PDF destroys GoBD compliance. | 10 years. The 16 July 2026 BMF action plan proposes 15 years (Measure 19) and mirror storage for some third-country cases (Measure 20). Design for 15. |
| Spain | Signed e-invoice, Verifactu chain, TicketBAI file where it applies | Follow AEAT / provincial rules; do not keep only the ticket PDF |
One object store with legal tags per document is cheaper than three "archive products." Export must produce the original bytes, not a regenerated visualisation.
Status and Cash Are Market-Specific
Poland: deemed receipt at KSeF assignment, UPO as delivery proof, KSeF number in the transfer title from 1 January 2027 for matching.
Germany: no state payment feed. Aging is your books plus the bank. Dunning is civil (Mahnung, BGB § 286 / § 288).
Spain: acceptance, rejection, effective payment date, 4 calendar days. Aging should show legal status next to days overdue.
A single DSO number across PL, DE, and ES is a management vanity metric unless you also split by market. Spanish 80-day SME waits and Polish 53-day average delays (Coface Payment Survey 2026) are different diseases. They need different evidence packs.
Build Order for a Multi-Market Operator
- Canonical invoice and buyer master data (tax IDs, Peppol IDs, invoice mailboxes, platform membership, Leitweg-ID).
- Polish adapter if you already issue in KSeF. It teaches you that the legal artefact is not the PDF.
- German validator and dual syntax before 1 January 2027 if your Gesamtumsatz will cross €800,000 in 2026.
- Spanish SIF / Verifactu if you take cash or issue tickets in Spain; Crea y Crece connector on the ministerial-order calendar.
- Cash application: SEPA remittance today, KSeF numbers in 2027, Spanish payment-date status as a first-class field.
Plandesk is that stack for shops and restaurants that already run POS and B2B on one database. The invoice is one row. The adapters are not a PDF plugin.
This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.