KSeF in a Polish housing community: receiving the invoice is the start of the process, not the end

Polish jurisdiction and the 2026 timetable

This guide concerns housing communities operating in Poland. Publishing it in English does not extend Polish invoicing rules to another country. KSeF is Poland's structured invoicing system. Ministry of Finance guidance describes mandatory receipt from 1 February 2026, subject to statutory exceptions, and phased obligations to issue invoices. For most taxpayers covered by those obligations, the issuing deadline was 1 April 2026. A temporary arrangement remains available through the end of 2026 for monthly sales documented by invoices not exceeding PLN 10,000 gross. KSeF financial penalties are scheduled to apply from 1 January 2027. [1]

These dates do not mean that every community has the same tax position. Its activities, tax status, customer type and basis for documenting charges must be assessed. An owner's advance payment and a contractor's invoice are not automatically equivalent events. Ask the accountant or tax adviser to determine the applicable obligations, then record that determination in the community's working procedure. Official sector training provides useful questions for this assessment. [3]

Assign responsibility before configuring software

Name the person who receives invoices, the person who checks the work and the person who approves expenditure. Provide cover for absence. Technical permission to retrieve an invoice should not automatically authorise a payment. One person may perform several steps, but the workflow must still distinguish those steps and their outcomes.

A useful responsibility record includes the community name, tax identification number, responsible person, deputy, permission scope and review date. If an administration firm serves several communities, create a separate record for each. A shared team is not a reason to mix client documents. A correctly downloaded invoice can still charge the wrong owners when it is linked to the wrong community.

Set a routine for collection and review that reflects payment deadlines. The routine should continue when a particular employee is absent. An overdue collection task needs to become visible before the underlying invoice becomes an overdue payment. Include a named recipient for escalations and a practical substitute channel if the usual application is unavailable.

Use the correct authorisation context

The Ministry of Finance describes access using a qualified electronic seal containing the community's tax identification number, or by designating an individual through a ZAW-FA notification. A properly authorised person can manage further permissions. Permission to access invoices can be granted separately from permission to issue them. [2]

Before configuration, check who represents the community and what authority has actually been granted. An employee does not become the community's legal representative simply because they keep its records. Retain the evidence supporting the permission and its scope. Where authority is unclear, resolve that issue before distributing broad access.

The access register should identify the person or organisation, community, permission, grant date, approver and review date. It should not contain secret values. Keep certificates and other authentication secrets in an appropriate protected facility. A permissions register explains authority; a secret store protects credentials. Combining them in a widely shared spreadsheet weakens both purposes.

Create a single document record

Once an invoice is received, preserve the identifiers needed to return to its source. These include the supplier's invoice number, KSeF number, parties, amounts, relevant dates and source document. Distinguish the issue date, receipt date, service date and payment deadline. A generic field labelled “date” conceals their different meanings.

Add the internal context: community, cost period, category, contract, purchase order or technical case. For example, an invoice collected in October might cover an inspection completed in September. Do not move a cost between periods solely because of the download date. Agree the applicable treatment with the person responsible for the records.

Show the work status separately: received, awaiting clarification, reviewed, approved, passed for recording, awaiting payment or settled. Different labels are acceptable if their meaning is clear. The essential point is that successful retrieval is distinct from substantive approval. Official guidance explains how invoice dates work in different KSeF modes; apply the rules for the actual mode involved. [4]

Check the invoice before releasing money

The review needs specific questions. Are the parties correct? Does the document concern this property? Has it already entered the records through another channel? Do the amount and scope match the order? Is evidence of completion available where the process requires it? Has a changed payment deadline been explained?

A new bank account should not be accepted solely because it appears on the invoice. Verify the change using an established contact channel with the supplier and retain the verification result. The document itself does not remove impersonation risk. A suitable record identifies the reviewer, date, channel and decision without copying unnecessary personal information from the conversation.

Assign every exception to a named person with a deadline. “Awaiting clarification” without an owner becomes a parking space for invoices. Also define who can release the hold and what evidence they must attach. If approval is conditional, make the condition visible to the person preparing the payment.

Check completeness and repeated documents

A successful download message does not establish that the whole expected range was received. Record the collection period, document count, outcome and exceptions. If a supplier announced an invoice that is missing, check the tax context and delivery method. Do not create a manual record without establishing whether the same document will appear during the next collection.

Check duplicates using identifiers rather than amount alone. Two different invoices can have the same value. One document may arrive as XML, a PDF visualisation and an email attachment. Keep one event record with its related representations. Restarting an integration after an interruption should not create a second liability for a document already received.

Also test whether another person can read the export. Include identifier definitions and relationship descriptions so the recipient can connect an invoice with its correction, approval and payment. A file that makes sense only inside the original application provides weak support for a change of administrator.

Example: one invoice, two different decisions

This is an illustrative workflow example, not an accounting instruction. A supplier invoices PLN 2,460 for maintenance. The administrator receives the document in the correct tax context. The technical reviewer confirms completion but finds that the contract specifies PLN 1,845 for the completed scope.

The invoice remains received, while payment waits for clarification of the PLN 615 difference. The record contains the contract, completion evidence and question sent to the supplier. A responsible person and response deadline are assigned. Any subsequent correction is linked to the original invoice instead of replacing it.

The invoice's valid technical status did not settle the pricing issue. It provided a clear source for further work. Once the discrepancy is resolved, the record should show the final amount, decision basis, approval and related payment. Months later, another employee should be able to reconstruct the sequence without searching a predecessor's private correspondence or asking them to remember what happened.

Keep recording and payment separate

Receipt does not establish payment, and payment does not establish that every document review is complete. Maintain separate information about entry into the records, approval and the actual bank transfer. Agree who updates each status and which evidence they use.

When importing bank transactions, link payments to invoices while checking partial payments, combined transfers and refunds. One invoice can have several payment events. One transfer can cover several invoices. A rigid assumption that every invoice matches exactly one transfer hides normal exceptions and encourages manual changes merely to make a report look tidy.

At the end of the period, reconcile documents awaiting approval, approved but unpaid invoices, unallocated bank transactions and corrections. The report should reveal differences rather than hide them. Changing the source document to force a match damages the evidence needed for the later settlement and makes the next discrepancy harder to explain.

Plan for interruption and a change of administrator

Define how the team works when its application, integration or KSeF is unavailable. Distinguish failure of your own tool from an official KSeF operating mode. Consult Ministry of Finance announcements and guidance for the relevant mode. A local software failure does not provide unrestricted discretion over how sales are documented. [4]

During a change of administrator, transfer the invoice list, unresolved exceptions, corrections and payment links. Review authorisations separately. Ministry guidance states that removing the permission manager's access does not automatically remove permissions previously granted to others. Review the entire community context, not just the departing employee's account. [2]

Test continuity in practice. The incoming person should locate an invoice, understand its review status and identify the next action. If a call to the former administrator is necessary to discover the basic status, the handover is incomplete. An exception register can preserve genuine uncertainty without allowing it to disappear.

Test the process in your chosen system

Use anonymised examples covering a normal invoice, a correction, an invoice assigned to the wrong community and a partial payment. Test retrieval, client assignment, review, exception hold, approval, settlement and export. Record the results and missing steps. A button labelled “KSeF” provides little information about the work that follows it.

WM Administrator describes its KSeF integration as part of an optional accounting module. Confirm the current module scope, configuration and required permissions before selecting it. Do not assume an integration replaces accounting judgement or a tax assessment.

View WM Administrator's scope and test your own process. A useful test lets you follow an invoice to its justified decision and follow a payment back to the supporting document, without guessing or depending on one person's memory.

Check the current module scope