Systems integration
KSeF 2.0 integration in practice: FA(3), offline24 and what changes in your ERP and online store
Published:
KSeF 2.0 integration is a data project with an API attached, not a sending project. In practice it means four workstreams: mapping every ERP field onto the FA(3) structured schema and deciding what belongs in the attachment, designing an issuing path that survives an unreachable API (offline24), treating KSeF certificates and issuing authorisations as production secrets with a named owner, and making your online store show order, invoice issued and invoice registered as three separate states. The technical integration is the easier half; the field mapping and the authorisation model are where projects actually get decided. Scope, deadlines and schema details must be verified against current Ministry of Finance and KSeF documentation and with your own tax advisor.
What KSeF 2.0 integration actually changes in your systems
Most teams treat KSeF 2.0 integration as a sending problem. It is a data problem with an API attached. Before the first call goes out, someone has to answer where each field of the structured invoice comes from in your ERP, who is allowed to issue an invoice in the company's name, and what happens to an order in your online store when the invoice cannot be registered at that moment. Integration work that starts at the API and ends there tends to need rework once the first edge case reaches accounting.
Primessio's team has 20+ years of IT delivery experience and 50+ rollouts behind it. That experience covers systems integration work: connecting finance, operations and sales systems that were never designed to talk to each other, which is exactly the shape of a KSeF programme.
FA(3) with an attachment: your invoice data has to carry more than a total
FA(3) is the structured invoice schema used with KSeF 2.0, and it allows an attachment next to the invoice body. That combination forces a decision most companies have never made explicitly: what is invoice data and what is supporting documentation. A line-item specification, a delivery breakdown or a service report may today live in a PDF that nobody parses. In a structured world you choose — model it as data, or carry it as an attachment and accept that it stays outside the structured record.
Run the mapping before you scope anything. Take a real month of invoices, not a template. For each field required by the published schema, name the ERP field that feeds it. The gaps you find are the actual project; everything else is plumbing.
Document types that break template thinking, and belong in the sample you map:
- Corrections and credit notes
- Advance and final invoices
- Foreign currency invoices
- Split payment cases
- Self-billing arrangements
- Intra-EU sales
Offline24 and the other issuing modes: design for the day the API is unreachable
Offline24 exists because invoicing cannot stop when a central system does. In practice it means your systems must be able to issue a valid invoice, hand it to the customer, and transmit it to KSeF afterwards within the deadline the regulations set. Architecturally that is a queue with state per document, a retry policy, an operator view of what is stuck, and an alert before a document ages past the limit — not a try/catch around an HTTP call.
The failure mode we watch for is silent: a document that failed to transmit, no owner, no alarm, discovered at month end. Decide up front who sees the queue every morning and what they are expected to do with it. The current deadline and the conditions attached to each issuing mode should be read in the official KSeF documentation, not in a summary.
Certificates and authorisation: the part teams underestimate
KSeF certificates are production secrets, and they behave like every other secret: they expire, they get copied onto a developer's laptop, and nobody owns them until something breaks. Give them a named owner, controlled storage, a rotation plan and an access list. Then map authorisations against reality: who may issue invoices for the company, whether your accounting office issues on your behalf, and what happens when that person leaves.
Dariusz Wtyklo, owner and CEO of Primessio, describes the working order plainly on his own page: "I start with your process and the way you work: I put them in order, and only then choose or build technology made to measure." For KSeF that order matters more than usual, because the technical integration is the easy half.
Inside the ERP: field mapping, numbering and the reconciliation loop
Three things usually need work in the ERP itself.
- Field coverage, because the schema asks for data the system never stored.
- Numbering and identifiers, because you now need to reconcile your own document number with the reference KSeF returns.
- The reconciliation loop itself: a scheduled comparison of what you believe you issued against what the register actually holds, with a report a controller can read without asking IT.
Team experience includes projects for Poland’s State Fire Service, where the system served 22,000 users on a project budget of PLN 20.3 million. Experience from projects at T-Mobile, ING Bank Slaski, PKN Orlen, the Ministry of Finance and the systems integration during the BGZ and BNP Paribas merger sits behind how we approach reconciliation — as project experience of the team, not as a client roster of Primessio. In regulated environments, the report that proves the state is part of the deliverable, not an extra.
Inside the online store: what the customer sees while an invoice is pending
The store's job is to stop pretending the invoice is instant. Order paid, invoice issued and invoice registered become three distinct states, and each needs a truthful message in checkout, in the customer account and in your support tooling. B2B buyers will ask where their invoice is; corrections and returns will collide with documents already in the register. Model those paths deliberately and your support team has a truthful answer ready for every state a document can be in.
The team's experience covers rollouts at a scale of PLN 20 million with delivery teams of 5 to 75 people. The relevant part for a KSeF programme is coordination: ERP vendor, accounting office, shop platform and internal finance all have to move in one sequence, which is a project management problem before it is a coding problem.
An 8-point readiness checklist you can complete today
Answer these eight in writing, on one page.
- Which entities and invoice types are in scope for you, per your tax advisor.
- Which ERP or invoicing system issues each document type today.
- Which required schema fields have no source in your systems.
- What goes into the structured invoice and what stays in the attachment.
- Who owns the KSeF certificates, and how they are stored and rotated.
- Who may issue invoices in your name, including any external accounting office.
- What your systems do when transmission fails, and who watches the queue.
- What your shop shows the customer between order and registered invoice.
If you can answer all eight, you are ready to scope. If three or more are blank, the gaps are the scope — and that is the honest starting point for a conversation.
Where our experience comes from
Primessio delivers from the Warsaw area, a 1–2 hour flight from the DACH region, with client data kept in the EU. We are a software house that optimises instead of complicating: first we understand the business, then the technology. Less, but better — that is how we scope an e-invoicing programme too. The work sits across custom software and systems integration, websites and online stores, project management and PMO, and nearshore software development in Poland.
A compliance note, stated plainly: this article explains integration mechanics, not law. We support compliance work on the technical side; we do not provide legal or tax advice, and scope, deadlines and schema details must be verified against the current Ministry of Finance and KSeF documentation and with your own tax advisor. We make no claim about processing times or outcomes we cannot measure.
Talk to us about your KSeF programme
Fill in the 8-point readiness checklist above and send it to info@primessio.com, or use the contact form at primessio.com/en/contact/ with one sentence about what you invoice and in which system. We will arrange a call and work through the gaps with you.
Author: Dariusz Wtyklo, owner and CEO of Primessio (ACTIVE IT), Warsaw, Poland — 20+ years of IT project delivery, PRINCE2, Agile and IPMA. As of August 2026.
Frequently asked questions
What is KSeF and does it apply to a foreign company with a Polish entity?
KSeF is Poland's national e-invoicing system, in which structured invoices are registered centrally instead of being sent as PDFs. Whether your entity is in scope, and from when, is set by Polish regulations and depends on how you invoice in Poland. Confirm your own status with your tax advisor and against the current Ministry of Finance documentation before you plan the build. We support the technical side of compliance; we do not give tax or legal advice.
What is the FA(3) schema and what do we need to check in it?
FA(3) is the structured invoice schema used with KSeF 2.0, and it supports an attachment alongside the invoice body. The authoritative field list is the schema published by the Ministry of Finance, not a blog summary. Map every field your ERP produces against the published schema, mark the ones you have no source for, and decide field by field what belongs in the structured data and what stays in the attachment.
What is offline24 mode in KSeF?
Offline24 is an issuing mode in which an invoice is issued outside the system and transmitted to KSeF afterwards, within the deadline set by the regulations. For your architecture it means one thing: the invoice must be valid and deliverable to the customer before KSeF confirms anything. That requires a queue, a retry policy, a state per document and an alert when a document sits unsent. Confirm the current deadline and conditions in the official KSeF documentation.
Do we need a KSeF certificate to send invoices?
Sending through the API requires authentication material issued for your entity, and KSeF certificates are the mechanism KSeF 2.0 uses for it. Treat it as a production secret: controlled storage, a named owner, a rotation plan and a clear mapping of who may issue invoices in the company's name, including your accounting office if it invoices for you. Obtain the current issuing procedure from the official KSeF documentation.
Can our ERP connect to KSeF without custom development?
Sometimes. If your ERP vendor ships a KSeF module and your invoicing is standard, the module may cover you. Custom work usually appears where the data is: split payments, corrections, foreign currencies, self-billing, multi-company setups, and every field the ERP does not currently store. The honest test is the field-mapping exercise — run it first, then decide between the standard module and an integration.
How does KSeF affect an online store and its order flow?
The store has to stop assuming an invoice is available the moment an order is paid. Order confirmation, invoice registration and the document the customer downloads become three separate states, and your checkout, customer account and support tooling all need to show the pending state honestly. Get the states right and returns, corrections and B2B orders become paths you have designed rather than surprises for support.
Related service: Software & IT systems →