For a business operating in Poland, the useful KSeF development question is no longer simply whether software can submit an invoice. It is whether finance can tell what happened, recover from an interruption and reconcile the result with the ERP. Those operating requirements should shape an integration project from the start.
As checked on 27 September 2026, the official KSeF guidance describes phased mandatory issuance from February and April 2026, together with exceptions and transitional provisions. It also distinguishes receiving invoices from issuing them. Establish your entity's obligations with the responsible finance adviser using the official scope guidance before turning them into software requirements.
The buying opportunity is a reliable process
A connector that passes a demonstration may still leave staff switching between screens to investigate missing documents. The development opportunity is to close the gap between the accounting process and the technical interface.
Consider a hypothetical Polish wholesaler that creates invoices in an ERP and uses a separate order-management application. Finance needs to trace an order to the invoice, the submission attempt and the resulting KSeF reference. The sales team needs a trustworthy business status without gaining unnecessary access to financial records.
That is a concrete software scope. “Make our company KSeF compliant” is too broad to tell an engineering team what to build or a buyer what evidence to accept.
Inspect the existing product before commissioning code
Start with the ERP vendor's supported KSeF capabilities and current maintenance arrangements. Record the product version, available modules, supported interfaces and responsibilities for updates. A configuration or supported extension may solve the problem more efficiently than a separate custom service.
Where custom integration is justified, identify the exact gap: an additional source system, an approval workflow, reconciliation, exception management or integration with a customer portal. Keep the new component's responsibilities narrow enough to test.
The official integrator support page provides API documentation and change information. Require the supplier to identify the documentation version and environment used. An old integration proposal should not silently become the specification for a different interface.
Map financial records to application states
Define the identifiers that connect the order, ERP invoice, integration transaction and KSeF result. Preserve enough history to investigate an attempt without treating every technical event as a new business document.
For each state, answer three questions: what does it prove, who may act next and what evidence supports that action? “Sent” can mean that the local application queued a request, transmitted it or received a response. Those distinctions affect whether finance should wait, investigate or correct data.
Make your state descriptions understandable to operators. A raw HTTP response may be useful for engineering, while finance needs the document reference, reason for attention and permitted next step.
Give exceptions a named owner
Design the exception workflow before launch. Identify which failures can be retried under documented rules and which require a business decision. A malformed record, missing permission and temporary connectivity problem should not all trigger the same action.
A practical exception record includes:
- ▸The internal invoice and relevant business references.
- ▸The time and identity of the latest authorized action.
- ▸The operation attempted and the response received.
- ▸Whether the result is known, pending or requires investigation.
- ▸The proposed next action and the person responsible.
- ▸A trace of corrections and approved reprocessing.
Do not assume that resending is always safe. The integration needs a method for distinguishing a failed local attempt from a successful remote operation whose response was interrupted. Agree that behavior against the current API contract.
Treat offline workflows as explicit modes
Poland's official offline24 guidance describes a specific invoicing mode with its own requirements. It should not be confused with an application's generic queue for sending requests later.
Ask finance and the integration supplier to specify when a mode is used, the required document behavior, submission responsibilities and the evidence retained. The software should make the selected process visible to authorized staff rather than quietly switching behavior after an error.
Test the transition back to normal processing. Define how outstanding work is identified and how staff verify that it has been handled. Keep any applicable deadlines and document rules in a maintained requirements record, with an owner responsible for confirming changes.
Reconcile independently of the submission screen
A daily or otherwise agreed reconciliation process should compare the expected business documents with recorded outcomes. Set its frequency according to volume and operational need, rather than borrowing a number from a marketing guide.
Investigate missing references, unexpected duplicates and states that have remained unresolved beyond the agreed operating window. Decide whether the process generates a report, an alert or a task queue, and who must respond.
For the wholesaler, a useful acceptance test might start with a deliberately interrupted transmission and end with finance finding one correctly reconciled invoice. This tests the business outcome, not just whether a button displays a success message.
Include access and maintenance in the scope
Use the permissions and authentication arrangements approved for the organization. Document who can administer access, handle credentials and approve production changes. A supplier's development access should not become permanent privileged access by default.
Request an operational runbook, monitoring ownership and a process for reviewing API changes. Define which updates are included in maintenance and which require a separate scope decision. For general structure, see the custom software maintenance agreement checklist.
A sound first engagement may be an integration assessment, followed by a bounded remediation or build. The CRM and ERP statement-of-work guide provides a starting structure. Explore software engineering services and share your ERP, invoice flow and current failure cases to discuss a concrete KSeF engineering scope.