E-Invoice Finder
Menu
Countries Compare software Deadlines Guides Checker Check obligation
ENFRDEPLNL
Poland · KSeF accounts payable

KSeF supplier invoice approval and P2P workflow

Design a controlled KSeF supplier-invoice approval workflow with PO matching, exception routing, payment controls and vendor acceptance tests.

Quick verdict:
  • Scope: connect official invoice retrieval to the buyer’s own ERP and approval controls.
  • Risk: uncontrolled copies, weak exception ownership and master-data changes can lead to duplicate or misdirected payments.
  • Action: test the full path from KSeF number to an independently authorised payment batch.
Get Poland readiness reportOfficial sources
Last checked: 30 July 2026Based on official sourcesClear summaryBusiness guidance, not legal advice
Official sources prioritized
Last-checked dates visible
Free checker, no signup required

What you need to know

Guide

KSeF receipt versus internal approval

The Polish Ministry of Finance’s KSeF 2.0 Q&A states that buyer acceptance is not required in KSeF and that an invoice is regarded as received when KSeF assigns its KSeF number. This official receipt event should be recorded accurately, but it must not be presented as confirmation that goods were accepted, expenditure was authorised, the invoice was booked correctly, VAT may be deducted or payment may be released. Those are separate decisions made under the buyer’s purchasing, accounting and treasury arrangements. Recommended practice—not an official KSeF mandate—is to model two distinct states: ‘received in KSeF’ and ‘approved internally’. A useful status path is received, validated, assigned, matched, approved, scheduled and paid, with held or disputed branches. For example, an invoice can be received in KSeF on Monday, placed on hold because the service owner disputes delivery on Tuesday, and remain unpaid while the supplier resolves the issue. The company should not imply that it rejected or reversed KSeF receipt. Instead, it should retain the invoice and evidence, record the commercial dispute, and control payment separately.

Guide

Intake, identity and provenance

Use the KSeF number as the technical identity of an incoming invoice and ingest that invoice once. Official API documentation describes retrieval through GET /invoices/ksef/{ksefNumber}, metadata queries through POST /invoices/query/metadata and asynchronous exports through POST /invoices/exports; export packages include _metadata.json. SubjectType determines the party role used for retrieval, so configuration and tests must reflect whether the organisation is acting as buyer or in another supported role. Access also depends on the authentication context and granted permissions. Recommended internal controls are to preserve the original XML, KSeF number, retrieval timestamp, query or export context, relevant metadata and processing history. Store a checksum if the architecture supports it. Before creating an ERP payable, search both the staging layer and ERP for the KSeF number; then apply secondary duplicate signals such as supplier tax identifier, supplier invoice reference, date, gross amount and correction relationship. Email notifications and rendered PDFs may help people work, but they must point to the same record rather than create another payable. A recovery process should safely replay a failed import without duplicating the accounting document.

Guide

Routing and 2-way or 3-way matching

Route each record using legal entity, supplier, PO reference, cost centre, project, requester and amount. The routing engine should fail visibly when a company code or owner cannot be determined; a shared unassigned queue with a named operator is safer than silent default posting. For a 2-way match, compare invoice lines and totals with the purchase order. For a 3-way match, also compare quantities or value with a goods receipt or service-entry record. Define tolerances in company policy rather than inventing them in the connector. A concrete flow might take an invoice for 100 licensed seats, identify PO PL-4500123, confirm the ordered price and tax treatment, and compare the billed period with the service owner’s acceptance. A warehouse purchase might require PO, invoice and goods receipt. A rent invoice may follow an approved recurring-contract route instead. Recommended checks include supplier status, currency, arithmetic, tax coding, split or partial deliveries, prior billings and remaining PO value. These are recommended P2P controls, not statutory KSeF approval requirements. The system should explain every mismatch and send it to a specific owner rather than merely marking the record ‘failed’.

Guide

Exception, dispute and correction handling

Create explicit queues for no-PO invoices, price or quantity mismatches, missing receipts, unknown suppliers, tax-coding questions, suspected duplicates, corrections and possible fraud. Each exception needs an owner, reason, evidence, next action and aging clock. A disputed invoice remains a received KSeF invoice; the internal workflow may block posting or payment, but should not pretend to reject it within KSeF. Supplier communication and resolution should be linked to the same case. Corrections should be linked to their original invoices and assessed together. Do not net a correction against an unrelated payable simply because supplier and amount appear compatible. For example, if a supplier corrects the quantity on an invoice already posted but not paid, the workflow should identify the original KSeF number, place both records under coordinated review, recalculate the payable position and preserve the approver’s reasoning. If the original has already been paid, route the resulting debit or credit position according to accounting policy. Test partial corrections, repeated corrections and a correction received before the original has completed internal approval.

Guide

Approval roles and segregation of duties

Define who may request a purchase, confirm budget, acknowledge receipt or service delivery, code the invoice, resolve a mismatch, approve the expense, maintain supplier data, prepare a payment and release it. Appropriate separation depends on company size and risk, but one person should not be able to create a supplier, change bank details, approve the invoice and release payment without independent control. InvoiceRead and InvoiceWrite are distinct KSeF permissions; grant only the access needed for each integration or operator and keep internal workflow roles separate from KSeF technical scope. A practical approval matrix can route a marketing invoice to the requester for evidence, the budget owner for commercial approval and AP for coding, while treasury independently authorises the payment batch. Absence delegation should have start and end dates, scope limits and an audit trail. Emergency overrides need a reason and retrospective review. The official permissions guidance emphasises access limitation, auditability, onboarding and offboarding, and caution with broad delegated permissions. Review leavers, role changes, service accounts and dormant access regularly rather than relying only on the initial implementation.

Guide

Payment-release and fraud controls

Payment release should consume only internally approved, unblocked records and should recheck critical data at the point of scheduling. Compare beneficiary bank details with the independently maintained supplier master; flag recent bank changes, new suppliers, unusual payment destinations, altered payment references, urgent manual requests and unexpected changes from established patterns. A bank-detail change should be verified through a trusted channel using known contact information, not the contact details supplied in the change request. Prevent duplicate payment by enforcing KSeF-number uniqueness and checking secondary invoice attributes before both posting and payment. Payment proposals should show linked approval evidence, holds, corrections, credits and prior payments. Separate payment preparation from release, and require an independent review of exceptions. The Ministry’s issuing and receiving guidance raises practical concerns including false-payment scenarios and KSeF references in payments; companies should translate relevant official guidance into documented treasury procedures. Recommended fraud and payment controls remain company controls, not proof that KSeF itself approves the commercial obligation.

Guide

Worked scenarios and common mistakes

No-PO service: a consultant’s invoice arrives with a valid KSeF number but no PO. Intake creates one case, AP assigns the correct entity, the requester supplies the contract and service evidence, the budget owner approves or disputes it, and payment stays blocked until policy conditions are met. Employee purchase: an invoice connected with an employee transaction enters the appropriate organisational route, with employee evidence and cost ownership captured; it must not be paid twice through both expenses and AP. New supplier with changed bank details: onboarding, tax and master-data checks are completed independently before the invoice can join a payment proposal. Correction: a supplier issues a correction against a previously approved invoice. The system links both records, recalculates the outstanding position and asks AP to review the correction before payment. Duplicate copy: a PDF emailed by the supplier carries the same invoice details as a KSeF record; it is attached for convenience, not posted again. Common mistakes are treating KSeF receipt as business approval, using a PDF as the system of record, silently assigning unmatched invoices, allowing approvers to edit supplier bank data, losing original XML provenance, clearing holds during batch preparation, and testing only the happy path.

Guide

Monitoring, audit and security

Operate dashboards for unassigned invoices, match failures, blocked or disputed items, approvals nearing internal targets, due invoices, corrections awaiting linkage, duplicate alerts, recent supplier-master changes and failed imports. Reconcile retrieval coverage against metadata queries or exports so a healthy interface does not mask missing invoices. Investigate gaps by legal entity, SubjectType, time range and authentication context. Internal aging targets are operational choices and should not be described as statutory KSeF deadlines. Keep an immutable or tamper-evident trail of retrieval, transformations, assignments, field changes, match results, approvals, delegations, overrides, hold releases, payment references and user or service-account identities. Limit production access, protect credentials, rotate them according to policy and alert on unusual retrieval or permission activity. Evidence should let an auditor move from a payment back to the ERP document, approval case, original XML, KSeF number and relevant metadata. Periodically sample no-PO, employee-purchase, correction, duplicate, new-supplier and bank-change cases, and verify that onboarding and offboarding remove unnecessary permissions promptly.

Guide

Software and vendor decision criteria and next actions

Assess whether a product can retrieve by KSeF number, query metadata, process asynchronous exports and preserve _metadata.json without weakening provenance. Confirm supported SubjectType scenarios, authentication contexts, InvoiceRead scope and permission monitoring. Require idempotent imports, safe replay, KSeF-number uniqueness, correction linking, configurable 2-way and 3-way matching, explainable exception routing, dated delegations, segregation-of-duties rules, payment holds and a complete exportable audit trail. Ask how the vendor prevents an emailed PDF from becoming a second payable and how it reconciles missing records. Run acceptance tests with anonymised but realistic cases: a clean PO invoice, missing receipt, no-PO service, employee purchase, duplicate KSeF number, near-duplicate supplier reference, correction chain, new supplier, verified bank change, disputed invoice, permission loss and interrupted export. Record the expected owner, status, evidence and payment outcome for each case. Next, map current roles and ERP fields, define exception ownership, document supplier-master verification, agree company-specific matching tolerances, and pilot one legal entity before scaling. Obtain Polish tax, accounting or legal advice where interpretation is required; this workflow guidance is practical information, not professional advice.

Guide

Practical question summary

For KSeF supplier invoice approval and purchase-to-pay workflow: Most KSeF questions are about who must use the system, whether current accounting software is ready, how authentication works, how corrections are handled, whether ecommerce or ERP needs API integration, and how accountants access invoice data. This guide focuses on those operational decisions.

Guide

Decision framework for businesses

For KSeF supplier invoice approval and purchase-to-pay workflow: A KSeF-ready workflow should show who creates invoices, who submits them, who monitors status, who handles rejection or correction, how invoices are archived and how the accountant sees the records.

Guide

How to use this guide

Use this guide to decide whether KSeF supplier invoice approval and purchase-to-pay workflow affects your Poland workflow and which evidence is still missing. Start with KSeF authentication, structured invoice submission, invoice status handling, then test submit a KSeF invoice and simulate an API rejection before comparing software.

Guide

Data and terms to prepare

For KSeF supplier invoice approval and purchase-to-pay workflow, the important terms are KSeF supplier invoice approval and purchase-to-pay workflow, Poland, KSeF authentication, structured invoice submission, invoice status handling, corrections and rejections, accounting or ecommerce integration. Clean these fields in customer, supplier, tax and accounting records before rollout; otherwise validation and support issues appear during daily invoicing.

Guide

Software proof to request

For KSeF supplier invoice approval and purchase-to-pay workflow, ask vendors to show show KSeF authentication, submission status, corrections, permissions and accounting export using your examples. The demo should cover submit a KSeF invoice, simulate an API rejection, create a correction, verify user permissions and explain who handles errors, corrections, archive access and accountant handoff for KSeF authentication, structured invoice submission, invoice status handling.

Guide

Evidence before rollout

Keep official links, screenshots, test invoices and the decision reason for KSeF supplier invoice approval and purchase-to-pay workflow. For KSeF supplier invoice approval and purchase-to-pay workflow, the implementation file should prove how KSeF authentication, structured invoice submission, invoice status handling, corrections and rejections were checked, not just that a tool was selected.

Guide

Decision checkpoint

Do not close KSeF supplier invoice approval and purchase-to-pay workflow until someone can explain KSeF supplier invoice approval and purchase-to-pay workflow in Poland, name the workflow owner, show one tested invoice scenario and describe how the team avoids choosing software for Poland before proving the real KSeF supplier invoice approval and purchase-to-pay workflow workflow.

Checklist

Record KSeF receipt and internal approval as separate states with separate timestamps.

Enforce one intake record per KSeF number and make replay idempotent.

Preserve the source XML, metadata provenance, retrieval context and processing history.

Route every invoice to a legal entity, accountable owner and explicit exception queue.

Configure 2-way or 3-way matching from documented company policy and evidence.

Link each correction to its original invoice before recalculating the payable position.

Separate requesting, supplier maintenance, expense approval, payment preparation and release.

Independently verify new suppliers and bank-detail changes through trusted contact channels.

Reconcile retrieval coverage and monitor unassigned, aging, blocked, due and duplicate items.

Acceptance-test no-PO, employee, correction, duplicate, new-supplier and bank-change paths.

FAQ

Does a buyer approve a supplier invoice in KSeF?

No buyer acceptance is required in KSeF according to the Ministry’s KSeF 2.0 Q&A. The buyer’s commercial acceptance, accounting review and payment authorisation should be handled as separate internal controls; they must not be inferred from the KSeF receipt event.

When is a KSeF invoice regarded as received?

The Ministry’s Q&A says it is regarded as received when KSeF assigns its KSeF number. Capture that event faithfully, while keeping internal assignment, matching, posting, approval and payment statuses distinct.

How should PO matching work for incoming KSeF invoices?

Use invoice fields to identify the correct entity and PO, then compare lines, price and value; add goods-receipt or service-entry evidence for a 3-way match. Tolerances and exceptions should follow documented company policy, because these matching controls are recommended P2P practice rather than official KSeF mandates.

What happens when the buyer disputes an invoice?

Keep the received invoice and its provenance, place an internal payment or posting hold, assign an owner and record the dispute evidence and supplier communication. Do not describe the hold as rejection inside KSeF.

How should KSeF corrections be processed?

Link the correction to the original invoice, review the combined accounting and payment position, and preserve the decision trail. The workflow should handle corrections arriving before approval, after posting or after payment without offsetting them against unrelated invoices.

How can accounts payable prevent duplicate payment?

Make the KSeF number unique across intake and ERP posting, then run secondary checks on supplier, reference, date, amount and correction links. Repeat the control before payment, and ensure email or PDF copies attach to the existing case rather than create another payable.

Which roles and evidence should an approval workflow retain?

Retain the requester, receipt or service confirmer, budget owner, AP reviewer, exception resolver, payment preparer and payment approver as applicable, together with timestamps, evidence, comments, delegations and overrides. Keep supplier-master maintenance and payment release appropriately independent.

What should a KSeF AP software proof of concept demonstrate?

It should demonstrate complete retrieval, provenance preservation, idempotent import, permission-aware access, matching, correction links, exception ownership, audit exports and payment holds. It should also pass realistic failure tests, including permission loss, interrupted export, duplicates, disputes, new suppliers and bank changes.

What do businesses usually ask about KSeF?

For KSeF supplier invoice approval and purchase-to-pay workflow: They ask about software readiness, API integration, authentication, corrections, accountant access and ecommerce workflows.

What is the most practical KSeF risk?

For KSeF supplier invoice approval and purchase-to-pay workflow: The practical risk is late discovery that permissions, corrections or invoice status handling do not match the business process.

What should I test first for KSeF supplier invoice approval and purchase-to-pay workflow?

For KSeF supplier invoice approval and purchase-to-pay workflow, start with submit a KSeF invoice, simulate an API rejection, create a correction because those scenarios reveal whether the workflow is practical.

What is the main risk for KSeF supplier invoice approval and purchase-to-pay workflow?

The main risk is choosing software for Poland before proving the real KSeF supplier invoice approval and purchase-to-pay workflow workflow.

Key regulations, formats and terms

PolandKSeFKrajowy System e-FakturPolish Ministry of Financepodatki.gov.plstructured invoiceAPI authenticationinvoice correctionsaccounting softwareVATSMEecommerceEuropean CommissioneInvoicingEN 16931Directive 2014/55/EUstructured electronic invoiceVAT automationcross-border tradeKSeF supplier invoice approval and purchase-to-pay workflow

Poland — Country hub

Poland

Open country hub →

Use the country hub to see every related deadline, checklist, format guide and software comparison for this market.

Continue reading

Official sources

We prioritize official government and EU sources where available and keep last-checked dates visible for mandate-sensitive pages.