When does KSeF actually become mandatory, and for whom?
KSeF is announced as the mandatory system for B2B invoices in Poland. The Polish government has moved the exact start date several times; the most recent plan is a phased obligation from 2026 for large taxpayers, followed by the rest of the SME sector. We are monitoring the roadmap and will plan your integration so that it is running in the sandbox well before your deadline. Important to understand: once the mandate takes effect, the tax authority will no longer accept a paper or PDF invoice as a valid tax document. Anything you send outside KSeF formally does not count. Your customer may then be unable to reclaim the VAT, and you would effectively be left without a recognised invoice.
What is FA(3), and why is that schema so strict?
FA(3) is the XML schema that KSeF prescribes for electronic invoices: a detailed XSD with mandatory fields for parties, invoice lines, VAT codes and corrections. It is strict because the Polish tax authority can validate the content directly and only accepts an invoice after schema validation. Beyond pure schema checks, there are also business rules: certain combinations of VAT rates and invoice types are not permitted, NIP numbers must validate against the Polish register, and corrective invoices must reference the original invoice by UUID. We also perform this validation on our side before submission, so that rejections remain rare.
How do you connect SAP IDoc INVOIC to KSeF?
Through a middleware layer between SAP and KSeF. The IDoc is picked up (via RFC, a file port or an EDI broker), transformed into FA(3) XML, signed with the qualified certificate and submitted to KSeF. We write the receipt confirmation or rejection back to SAP, as IDoc status, a custom Z-table or e-mail notification, depending on what your SAP team prefers. We keep your SAP system explicitly clean: no Z-development within SAP and no changes to standard IDoc segments. All KSeF-specific logic sits outside SAP, in a separate service that we manage or that you can run yourselves after handover.
Can we test safely in a sandbox first?
Yes. KSeF has a separate sandbox environment that is identical to production in terms of API and schema. We build against it first, run a full end-to-end test with real invoice data, and only once the signature flow, submission, callback and error paths all work correctly do we switch over to production. The switch itself is a configuration change, not a code change. In the sandbox we also deliberately simulate failure scenarios: an incorrect VAT rate, a missing NIP, a timeout on the KSeF side, a revoked signature. Only once those paths are handled cleanly do we go live.
How do we connect Exact Online or AFAS to KSeF?
For Exact Online we build the integration on the Exact Online API; for AFAS we deliver via Profit connectors or GetConnectors. The integration layer between your accounting package and KSeF sits as a separate service, so an upgrade of Exact or AFAS won't break the KSeF integration. See also our
Exact Online integration page for the Exact side. For AFAS we typically use a GetConnector to extract invoice data, an UpdateConnector to write the KSeF status back, and a separate service for the KSeF submission itself. This keeps the AFAS environment within the scope of your AFAS consultant and the KSeF layer within ours.
Does this work alongside Peppol for other EU countries?
Yes. Peppol is emerging as the universal e-invoicing network for the EU, while Poland has its own mandatory system with KSeF. Many multinationals run into that parallel world. We build routing logic that chooses, per recipient country and VAT position, between Peppol, KSeF or another mandate (for example SDI in Italy or FacturaE in Spain). One platform, multiple channels, one shared audit log. That makes management far easier: one integration team, one set of monitoring dashboards, and one place where the finance controller can see rejected invoices.
What about archiving and the retention obligation?
Polish tax law requires invoice data to be archived for many years, usually ten. We set up encrypted storage in your cloud or with us, with write-once logging and an audit trail that shows who viewed or exported which invoice, and when. Access runs through your identity provider (Azure AD, Okta, Google Workspace), so it falls within your existing security policy. Alongside the FA(3) XML, we also keep the corresponding KSeF UUID, the acceptance timestamp and, where relevant, the original source IDoc or API response, so you can present the full trail in an audit.
What if KSeF rejects our invoice? Who corrects what?
Rejections come in various forms: schema errors (a field that doesn't match), business rule errors (an invalid NIP, an incorrect VAT rate), or technical errors on the KSeF side (timeouts, maintenance). We separate these paths in code: schema errors go back to your finance team with a clear explanation, business rule errors trigger a manual review, and technical errors are retried automatically with exponential backoff. Nothing disappears into a log file nobody checks. Everything appears on the operations dashboard with an action button.
What does a KSeF integration cost?
That depends heavily on scope. One ERP and one entity is a short engagement; a multi-entity setup with SAP IDoc flows and Peppol overlap is a larger one. In the first conversation we walk through the scope and then link back a sprint budget. No open-ended hourly billing; fixed budgets per sprint. We also state explicitly which risks fall outside the current scope (for example, new FA versions that Poland only publishes later) and how we handle them in maintenance without the project running on indefinitely.
