Poland · KSeF payment controls

KSeF supplier master data and bank-change fraud controls

Control supplier master data and bank-account changes around KSeF invoices with independent verification, VAT-list checks and payment-release evidence.

Quick verdict:
  • Treat a new payee account as a high-risk master-data event.
  • Make unresolved identity or remittance conflicts block the payment run.
  • Choose tooling that proves who checked what, when and against which source.
Last checked: 1 August 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

Quick risk model: five decisions, not one green light

Separate five decisions: is the invoice an authentic KSeF system document; is the supplier the legal entity you intended to buy from; is the proposed bank account valid for this payment; did the business confirm that goods or services were ordered and received; and may treasury release funds now? KSeF records support the first decision and its identity trail. They do not prove buyer approval, receipt of performance or authority to pay a particular account. Build five independently visible statuses rather than one ‘verified’ badge. For example, an invoice may pass KSeF retrieval and supplier-NIP matching but remain blocked because the purchase order is absent and the account changed yesterday. AP owns document and master checks, the requester owns business acceptance, tax or accounting specialists interpret list and payment-mechanism issues, and treasury owns release. Test these outcomes quarterly with clean, mismatched, duplicate and unverified cases.

Guide

Create a trustworthy supplier onboarding and master record

Onboarding should begin with the supplier’s legal name, NIP and other stable legal-entity identifiers, registered address, contracting entity, payment terms, tax status and approved remittance account. Collect evidence through a controlled channel and validate identifiers against reliable records; do not let free-text names become the matching key. Search the ERP for the same NIP before creating a supplier so spelling differences do not produce duplicate vendors. Record the source, checker, date and result of each validation, then require an independent approver before activation. The procurement or vendor-management owner should confirm the commercial relationship, while AP confirms the accounting record and a designated master-data approver releases it. Useful tests include attempting to create a second record with the same NIP, omitting mandatory ownership evidence and assigning one user both creator and approver rights. Software should reject or escalate all three. Re-certify high-risk suppliers and retain prior master versions.

Guide

Secure every supplier bank-account change

Treat any account addition or replacement as a privileged change, even when it appears on a genuine invoice. Route requests into a dedicated queue, lock the existing master value while review is open and compare the legal entity, NIP, account holder, currency, country and effective date. An independent employee must call back using a pre-existing trusted contact obtained from the approved supplier record or another independently sourced channel—not a telephone number or email contained only in the invoice or change request. Record who was reached, the trusted source used, questions answered and outcome; preserve the request and callback evidence. Apply dual approval and, where proportionate, a cooling-off or risk hold before first payment. Alert treasury to the change and show both old and new account values in the payment review. Test a lookalike domain, simultaneous contact and account changes, urgency and self-approval; each must block or escalate.

Guide

Match KSeF, ERP and procurement data—and own exceptions

Ingestion should retain the KSeF number, structured invoice data, retrieval timestamp and source response, then match the supplier NIP and legal entity to the approved master. Detect duplicate KSeF numbers and likely economic duplicates such as the same supplier, invoice reference, date and gross amount. Compare purchase order, receipt or service acceptance, contract, currency, tax amounts and payment terms before posting or release. Do not automatically replace ERP bank details merely because a different account appears in invoice data. Define exception classes and owners: AP handles duplicate and field mismatches, procurement resolves missing orders, the requester confirms receipt, master data investigates supplier conflicts, and tax specialists assess VAT treatment. Set internal targets by risk, not as supposed KSeF deadlines. Test that each changed identifier reaches the right queue, blocks payment and requires an authorised, evidenced resolution.

Guide

Use the VAT taxpayer list, ZAW-NR and MPP carefully

The official Wykaz podatników VAT, commonly called the Biała lista, is a separate check from KSeF. Where relevant, query it for the supplier and account for the date required by your policy and Polish rules, and retain the query parameters, result, timestamp or official confirmation so the evidence can be reproduced. An absent or conflicting account is an exception to investigate, not a reason to substitute an account informally. The official ZAW-NR page explains that when payment for an active VAT taxpayer’s invoice was transferred to an account not listed on the transfer-order date, ZAW-NR may be relevant; it currently states a seven-day filing period and describes possible PIT/CIT cost and joint VAT liability consequences. Confirm applicability and action with Polish tax or accounting advisers. Likewise, assess MPP scope rather than applying it blindly: official guidance describes PLN bank transfers to other VAT taxpayers, with net funds sent to the settlement account and VAT to the VAT account, and mandatory MPP for covered purchases above PLN 15,000 gross. Retain the adviser decision with the payment.

Guide

Separate payment approval from master-data administration

No person should be able to request a supplier, validate its account, approve the invoice and release the payment alone. Use role-based permissions for requester, master-data maker, master-data checker, AP processor, business approver and treasury releaser; review conflicts and emergency access regularly. Payment runs should expose new suppliers, recently changed accounts, first payments, high values, split invoices, unusual currencies, weekend or urgent runs and overridden exceptions. A second treasury reviewer should compare the payment run to approved invoices and current master data before bank release. Require step-up approval or a temporary hold for recent account changes, with a documented risk owner for any override. Evidence should include approval identities and times, master-data version, exception decisions, payment-run totals, bank file hash or reference, and bank acknowledgement. Test self-approval, blocked payment-file export and post-approval edits; the system must deny, invalidate or alert.

Guide

Respond to suspicious or scam invoices before money moves

When an invoice, supplier message or account change looks suspicious, stop payment and freeze related master-data edits first. Preserve the KSeF number, structured payload, invoice rendering, emails with headers, call records, ERP audit trail, VAT-list evidence and bank payment-file data. Notify the named fraud or incident owner, AP leadership, treasury, information security and legal or tax specialists as appropriate; contact the supplier only through a trusted pre-existing route. Check related invoices, users, changed contact records and pending payment runs, and ask the bank about containment promptly if payment has already left. The KSeF 2.0 taxpayer application’s official explanations include scam-invoice reporting, but submitting a report does not replace investigation, evidence preservation or payment controls. Record the chronology and recovery, reset compromised access and test both pre-payment containment and post-payment response.

Guide

Worked scenarios and common mistakes

Scenario one: a familiar supplier’s valid KSeF invoice names a new account and demands same-day payment. KSeF retrieval passes, but AP keeps the old master value, opens a bank-change case and calls the known finance contact from the approved record; the contact denies the request, so treasury blocks payment and the incident owner preserves evidence. Scenario two: the callback confirms a legitimate change, but the account is not returned by the relevant VAT-list check. AP does not improvise: tax or accounting advisers assess the payment date, ZAW-NR relevance and MPP scope, while approval remains explicit and documented. Scenario three: the account is unchanged and list evidence is clean, yet no receipt exists. The business owner—not KSeF—must resolve delivery before release. Common mistakes are treating a KSeF number as a safe-to-pay flag, accepting screenshots as bank proof, calling numbers supplied only in the request, letting invoice import overwrite master data, clearing exceptions without reasons, checking the list without retaining date-specific evidence and allowing urgency to bypass dual approval.

Guide

Software decision criteria and next actions

Evaluate AP automation, supplier-master and ERP tools against observable controls, not generic ‘KSeF ready’ claims. Require stable NIP-based matching, duplicate prevention, versioned master data, locked bank changes, maker-checker approval, trusted-contact callback evidence, configurable risk holds, dated VAT-list evidence, PO/receipt/invoice matching, granular permissions, payment-run review, account-change alerts, immutable audit logs and owned exception queues. Ask vendors to demonstrate a genuine KSeF document with a fraudulent account change, duplicate and missing receipt. Score default blocking, approval invalidation, evidence export and safe API failure. Next, map current roles and bank-change routes, sample recent supplier amendments, reconcile ERP accounts to retained evidence, identify segregation conflicts and assign remediation owners. Pilot the controls, secure owner and adviser sign-off, then assess exceptions before expanding automation.

Checklist

Assign separate owners for document authenticity, supplier identity, account validation, business acceptance and payment release.

Use NIP and stable legal-entity identifiers to prevent duplicate supplier records.

Lock bank changes until an independent checker approves retained evidence.

Call back through a pre-existing trusted contact, never details supplied only in the request or invoice.

Capture the relevant dated VAT taxpayer-list query and its result.

Escalate ZAW-NR and MPP applicability to Polish tax or accounting advisers.

Block invoices with unresolved PO, receipt, identity or remittance exceptions.

Flag first payments, recently changed accounts and overrides in every payment run.

Test segregation by attempting self-approval and post-approval beneficiary edits.

Preserve KSeF, ERP, communications and bank evidence during suspected fraud response.

FAQ

Does KSeF verify a supplier’s bank account?

Do not treat KSeF as bank-account approval. KSeF establishes the structured invoice and system identity trail, while account validation remains a separate buyer control. Compare the proposed account with the approved supplier master, perform relevant VAT taxpayer-list checks and independently verify any change through a trusted pre-existing contact before payment release.

Is a KSeF invoice automatically safe to pay?

No. Receipt through KSeF does not prove that your business ordered or received the goods or services, approved the invoice, or authorised a particular beneficiary account. Complete supplier identity, PO or contract, receipt, tax-list, bank-change and payment-approval checks according to risk.

How should we verify a supplier bank change?

Freeze the update, compare legal-entity and account details, and have an independent employee call a trusted contact already held in the approved record or sourced independently. Retain the source, person reached, outcome and approvals. Never rely only on contact details included in the change request or invoice.

What if the account is not on the Polish VAT taxpayer list?

Stop and investigate rather than changing course informally. Retain evidence of the query for the relevant date and ask Polish tax or accounting advisers to assess the facts, including whether ZAW-NR or MPP is relevant. The official ZAW-NR page currently describes a seven-day filing period in applicable circumstances.

Does every KSeF invoice require split payment (MPP)?

No blanket conclusion should be drawn. Official guidance describes MPP for PLN transfers to other VAT taxpayers and mandatory use for covered purchases above PLN 15,000 gross. Have a qualified Polish adviser confirm scope for your transaction and document the decision in the payment record.

Can a suspicious or scam invoice appear in KSeF?

KSeF should not be described as eliminating invoice or payment fraud. Its official explanations include scam-invoice reporting in the KSeF 2.0 taxpayer application. If something is suspicious, stop payment, preserve evidence, investigate connected activity and use trusted supplier contacts; reporting alone is not a containment plan.

What evidence should AP retain?

Keep the KSeF number and payload, retrieval record, supplier identifier match, master-data versions, bank-change request, independent callback proof, dated VAT-list result, PO and receipt match, exception decisions, approvals, payment-run record and bank acknowledgement. Evidence should show the actor, timestamp, source and result.

What should we test when buying AP or supplier-master software?

Ask the vendor to demonstrate duplicate-NIP prevention, maker-checker bank changes, role conflicts, trusted callback records, VAT-list evidence, KSeF and ERP mismatches, payment holds, approval invalidation after edits and audit export. Include a fraudulent urgent change and confirm the system fails safely without silently updating the beneficiary.

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 master data and bank-change fraud controls

Poland — Country hub

Continue reading

Official sources

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