Skip to content
Foundations and applications5 min read

KSeF preparation: systems, data and invoicing workflows

Prepare your business systems for KSeF: map invoice data, manage permissions, test FA(3) integration and plan reliable handling of errors and disruptions.

KSeF, Poland’s National e-Invoicing System, changes how businesses issue and receive structured invoices. Preparing for it involves accounting rules, software integration and daily operating procedures. An XML file that passes validation is only one part of a working invoicing process.

This guide focuses on technical and organisational preparation. For current obligations, exceptions and transition arrangements, use the official Ministry of Finance KSeF portal and confirm the rules relevant to your business with your accountant.

Establish which rules apply

The main implementation dates are 1 February 2026 for businesses whose gross sales exceeded PLN 200 million in 2024, and 1 April 2026 for the next group of businesses. Exceptions and transitional provisions require a separate check. VAT exemption does not, by itself, mean that a business can wait until 2027.

Map the transactions you actually handle: domestic sales, sales to foreign customers, consumer transactions, advance payments and corrections. A foreign buyer does not automatically exempt a Polish issuer from KSeF obligations.

Record who owns interpretation of the rules, who maintains the integration and who resolves rejected or disputed invoices. These responsibilities should remain clear after the initial launch.

Inventory systems and invoice flows

List every system that creates or receives invoice data: ERP, accounting software, e-commerce platforms, billing tools and manually maintained spreadsheets. Identify the authoritative source for customer details, tax treatment, invoice numbers and line items.

For each flow, document:

  • What triggers an invoice and who approves it.
  • Which system sends the invoice and retrieves its status.
  • How the KSeF identifier and confirmation are recorded.
  • How incoming invoices reach accounting and approval workflows.
  • What happens when data are incomplete, duplicated or rejected.

This is also a useful point to review business process automation. Automating a poorly understood approval chain can make its errors harder to investigate.

Map data to the current structure

Use the applicable FA(3) structured invoice specification and current API documentation. Map fields explicitly instead of assuming that an existing PDF or spreadsheet contains everything the schema requires.

Check mandatory and conditional fields, tax calculations, currency handling, rounding and corrections. Include examples from real business processes, with test data that do not expose unnecessary personal information.

Schema validation confirms structural requirements. It does not confirm that the invoice reflects the correct transaction or accounting treatment. Finance and technical teams need a shared acceptance checklist.

Design authentication and permissions

Choose an authentication method supported by the current KSeF rules and the organisation’s operating model. Keep credentials and certificates out of source code and ordinary shared documents. Define access, rotation, revocation and recovery procedures.

Separate the ability to issue invoices from administrative access where practical. Document how external accounting providers receive and lose authorisation. Authentication to KSeF is a separate concern from assuming that every invoice needs an individual electronic signature.

An integration should leave a useful audit trail without logging unnecessary invoice contents or secrets. For broader access design, see Zero Trust architecture.

Test the full lifecycle

A meaningful test covers more than a successful submission. Include:

  1. Valid invoices across the transaction types in scope.
  2. Invalid or incomplete data and understandable error messages.
  3. Status retrieval and recording of the KSeF identifier.
  4. Retries that avoid creating duplicate business records.
  5. Incoming invoices, approvals and reconciliation with the ledger.
  6. Corrections and links to the original document where required.
  7. Access changes, expired credentials and recovery.
  8. Busy periods, interrupted connections and service disruption.

Agree acceptance criteria with accounting staff. An error that a developer can diagnose from a log may still block the person responsible for closing the month.

Prepare for disruptions and corrections

Offline24, announced unavailability and system failures have different conditions and deadlines. Do not apply one universal “send within 24 hours” rule to every situation. Build procedures around the current official guidance for each mode.

Define how staff recognise the active mode, issue documents, communicate with recipients and submit or reconcile them later. Test recovery as carefully as normal operation.

An accepted invoice cannot simply be overwritten. Corrections must follow the applicable rules and supported document flows. Avoid carrying forward assumptions about correction notes or other procedures from an earlier regime without checking them.

KSeF storage also does not settle every recordkeeping obligation. Decide which supporting documents, accounting records and technical evidence the organisation must retain and for how long.

Questions for a software supplier

Ask the supplier to demonstrate the current schema and API version, supported transaction types, error handling and recovery procedures. Request a clear description of what is included in the service and who maintains compatibility when specifications change.

Useful evidence includes test results, operating documentation and an agreed support process. A claim of “KSeF readiness” is less informative than a demonstration of your own invoice lifecycle. Do not assume that an integration has an official certification unless the supplier can identify the relevant certification scheme and evidence.

Assess costs across implementation, licences, hosting, support and future changes. Any estimate depends on the existing systems and the scope of work.

Where QA10 can help

Q-Dev can develop individual software and integrations around an agreed invoicing process. Where the wider process needs assessment first, Q-Journey begins with an audit and can continue into software delivery, with or without AI.

The scope, acceptance criteria and schedule are agreed for the project. Technical implementation supports the organisation’s accounting and compliance work; it does not replace decisions by the people responsible for those obligations. Discuss your process with QA10.

FAQ

Does a foreign customer make an invoice exempt from KSeF?

Not automatically. A Polish issuer must assess its own obligations and the transaction under the applicable rules. The customer’s location alone is not a sufficient basis for excluding an invoice.

Is FA(2) the structure to use for the 2026 integration?

Preparation should use the applicable FA(3) specification and current KSeF documentation. Check the supported schema and API versions with your software supplier and the Ministry of Finance.

Must every invoice be sent within 24 hours during a disruption?

No universal deadline covers every disruption mode. Offline24, unavailability and system failures have different rules. The procedure must identify the applicable mode and follow its current official requirements.

Does buying an integration complete KSeF preparation?

No. The organisation also needs correct source data, permissions, acceptance tests, accounting procedures, monitoring and a clear owner for errors and changes. A working connector is one part of that process.

Back to the knowledge base

From understanding to action Q-Journey

From business processes to practical change

Explore the path from company AI and an audit to software and ongoing development.