Poland KSeF E-Invoicing

The problem

KSeF is a clearance model, and that changes the accounting reality. The government platform holds the legal invoice of record. A document is not legally issued because you posted it in the ERP — it is issued when KSeF accepts it and assigns a number. Until the UPO (the official confirmation) is retrieved and stored, you have a posted transaction with no proof that the invoice legally exists.

That imposes requirements Dynamics 365 Finance & Operations does not meet out of the box for the Polish flow. The invoice must be serialised into the structured FA schema, not a generic XML. Submission is session-based: open a session, authenticate, send documents, close the session, then poll for the UPO — which does not come back instantly. The KSeF number returned must be stored against the invoice and reproduced on any document you give the customer. Corrections and credit notes have their own referencing rules. And JPK reporting has to reconcile against what KSeF actually holds, not against what your ledger thinks it sent.

Without a proper integration, the failure mode is quiet and expensive: invoices that posted but never cleared, UPOs nobody retrieved, and a reconciliation gap discovered at reporting time rather than at issue time.

What ECOSIRE builds

ECOSIRE builds a KSeF extension for your F&O environment, developed against your legal entity structure, tax configuration and document flows. It is built after scoping — not downloaded.

Structured FA schema serialisation

Posted customer invoices, correction invoices and free text invoices are serialised into the structured FA schema. Mapping is configuration-driven: seller and buyer identification, line-level item data, tax rates and categories, payment terms, delivery dates, and the correction referencing that ties a credit note back to the original KSeF number. Serialisation runs off the posted document so the cleared invoice matches the ledger.

Session handling and submission

The extension implements the full session lifecycle — authentication with your KSeF credentials, session open, document submission, session close — as a managed sequence rather than a fire-and-forget call. Session state is persisted, so a process interruption does not leave documents in limbo. Batch jobs handle submission, and a separate polling job retrieves the UPO once it becomes available.

KSeF number and UPO custody

The assigned KSeF number is written to the invoice header and made available to the invoice report, so the document you send a customer carries the identifier that makes it verifiable. The UPO is retrieved, archived against the invoice and retained. A workspace shows every posted invoice whose clearance status is anything other than accepted-with-UPO, which is the control that prevents a reporting period closing over an uncleared document.

Corrections and edge flows

Correction invoices reference the original KSeF number per the schema rules. Documents rejected by KSeF are held with the rejection reason attached, corrected, and resubmitted through an explicit action with a retained history — never silently reissued.

Platform mechanics

• X++ extension model with event handlers, extension classes and Chain of Command. No overlayering, so one-version upgrades are unaffected.
• Data entities for KSeF configuration, session log, submission status and UPO reference, exposed over OData for external monitoring or a Power Platform surface.
• Batch framework jobs on dedicated batch groups for submission, UPO polling and reconciliation, each independently schedulable.
• Ledger dimensions read from the posted invoice and preserved without modification.
• Payload and UPO archival per document, so an audit can be shown the exact structured file that was cleared.
• Per-legal-entity configuration, so Polish entities clear through KSeF while other entities in the same instance are untouched.

Who this is for

Polish legal entities running Dynamics 365 Finance & Operations that must issue invoices through KSeF. It suits international groups where Poland is one entity inside a shared F&O instance and the clearance flow has to be isolated, and it suits shared service centres issuing Polish invoices on behalf of an operating company that need clearance status visible in F&O rather than in a separate portal.

It is equally aimed at finance teams who have to defend a JPK submission and need a defensible link between the ledger, the cleared structured invoice and the retained UPO.

How delivery works

1. Scoping call. We review your Polish legal entities, invoice and correction types in scope, tax configuration, KSeF authentication method, volume, and whether inbound receipt is required.

2. Fixed quote. A written scope covering FA schema mapping, session handling, UPO retrieval, batch jobs, entities and acceptance criteria, at a fixed price.

3. Build. Development against the same platform and application version you run, with schema validation on the serialised output and unit tests over the mapping layer.

4. Install in test. The deployable package goes through your LCS/sandbox pipeline into test. We run the full clearance cycle against the KSeF test environment with your own data, including a correction scenario and a rejection scenario, and hand you a test script for sign-off.

5. Production. The same package is promoted after sign-off. We are on hand for the first live clearances and the first UPO retrievals.

6. Support. A defined post-go-live support window for defect fixes and configuration questions, with source code in your hands throughout.

Lead time and honesty

There is no ready-made download and no trial. The extension is built for your environment after the quote is signed — typically two to four weeks to a working install in test, longer where correction flows, multiple entities or inbound receipt are in scope. Clearance is a legal path, so the value is in the schema mapping, the session handling and the UPO custody being correct for your setup, and that work starts once we have seen it.