KSeF and the three-way match: closing the purchase-to-pay loop in Poland
A practical guide to connecting structured invoices, purchase orders and goods receipts, with clear ownership of exceptions.
Start with the buyer's problem
A purchase order records what the buyer agreed to buy. A receipt records what arrived. An invoice asks for payment. These documents often reach different people at different times. The buyer sees an approved order, the receiving team knows about a partial delivery, and accounts payable sees a bill for the whole order. Matching brings those views together before someone decides what to do next.
The invoice leg used to be a weak link because its data needed to be read from an attachment or entered again. A clear document could still lack the order reference. A scanned copy could hide a unit or a decimal separator. Structured data removes some transcription work. It does not remove the need to understand the purchase, the delivery and the terms agreed with the supplier.
What KSeF contributes
KSeF is Poland's national system for structured e-invoices. FA(3) is the logical invoice structure. It carries defined fields rather than just a picture of a bill. UPO is an official acknowledgement associated with processing in the system. Keep identifiers and acknowledgements available to the people responsible for invoice records. They help establish which document was processed and connect operational work to the source invoice.
Flow Procurement's integration is built on the official KSeF API 2.0. For a buyer, the useful question is how incoming invoice data reaches the order record. A technical connection is only one part of that answer. The organization also needs the right permissions, valid supplier data and a process for deciding whether a proposed link is correct. An invoice arriving through KSeF is not evidence that goods were received.
Keep the three documents distinct
The purchase order should retain the agreed item, quantity, unit, unit price and supplier. It also needs a stable order number. A goods receipt should record accepted quantities against order lines. Record a partial receipt as partial. Do not mark an order complete merely because the supplier says that the rest is coming. Services need an agreed acceptance record that serves the same operational purpose.
The invoice supplies the billed quantities and prices. Compare it with the order and the receipt using consistent units and currency. Keep tax treatment visible to the accounting owner. Do not let a buyer change source invoice fields just to make a match pass. When the source is wrong, record the issue and follow the correction process. The match should explain the disagreement, not erase it.
Read statuses as work queues
Matched means the compared records agree within the configured rules. It should still be possible to open the underlying documents. Quantity mismatch means billed and accepted or ordered quantities differ. Price mismatch means the billed price differs from the agreed comparison basis. Missing invoice means the order or receipt has no linked invoice. Missing receipt means the invoice has arrived without the acceptance record needed for comparison.
Each status needs an owner and a next action. A missing receipt may belong to the receiving team. A price mismatch may need a buyer to check the contract. A missing invoice may need supplier follow-up. Avoid treating every exception as a payment rejection. Some exceptions reflect timing. Others reflect a real commercial disagreement. Keep the reason and the resolution attached to the order so the next reviewer can understand the decision.
Link invoices carefully
The strongest starting point is a purchase order number carried on the invoice. Agree the format with suppliers and show it clearly on the order. Check that the referenced order belongs to the same supplier and that its lines make sense for the invoice. A reference alone should not connect an invoice to a different supplier's order. Handle invoices covering several orders as an explicit allocation task.
When the order number is missing, supplier identity plus amount can narrow the candidates. Use the supplier tax ID rather than a loosely spelled name. An amount match is a clue, not proof. Repeated purchases can have the same value. Currency, dates and remaining uninvoiced lines may help a reviewer decide. If several candidates remain, ask for a decision. Keep the original document and the reason for the chosen link available.
Set tolerances before using them
A tolerance defines which small differences your organization accepts for a particular comparison. It may address rounding or an agreed practical limit. Decide who owns the rule and which categories it applies to. Document whether a rule compares each line or the whole document. A total can look correct while one line is wrong. Consider how freight, discounts and different units affect the comparison basis.
Do not use a wide tolerance to hide poor data. Review rejected and accepted examples with accounts payable and buyers before enabling a rule. A tolerance does not grant permission to change contract terms. Keep the rule used for a decision visible, and route cases outside it to a person with authority. Review the policy after the pilot using actual exceptions rather than an assumed target match rate.
Prepare people and data
Clean supplier tax IDs and remove duplicate supplier records before importing invoices. Tell suppliers where to put the order number. Agree who records receipts, including partial deliveries and service acceptance. A structured invoice cannot repair a receipt that nobody recorded. Give the receiving team a short process they can follow at the time of delivery. Define how rejected or returned items are handled in that process.
Accounts payable should help design exception queues and the handoff to accounting. Buyers should know when they can resolve an issue and when they need approval. Keep the meaning of a match separate from payment authorization. Build a small test pack containing a clean match, a partial delivery, a changed price, an invoice without an order reference and an invoice without a receipt. Use it to check the whole workflow.
Separate testing from production
Use the KSeF test environment to exercise authentication, retrieval and error handling with suitable test data. Production permissions and certificates are a separate project task. Assign an owner for obtaining them, storing them on the server and maintaining access when people change roles. Confirm which entity the integration acts for. Do not copy credentials into browser code, screenshots or supplier instructions.
Before go-live, run the agreed test pack and record who resolves each exception. Check that repeated imports do not create duplicate invoices. Confirm that a failed import can be retried and that operators can see its state. Make the production handover explicit: environment, access owner, supplier records, receipt owners and support contact. The useful outcome is a traceable purchase-to-pay process, not simply a connection that returns data.
Official references
See the KSeF integration documentation and the Ministry of Finance publication on API 2.0 and FA(3).
Checklist
- Confirm supplier tax IDs and remove duplicate records.
- Agree the PO reference format with suppliers.
- Name receipt owners and record partial deliveries accurately.
- Document comparison units, tolerances and exception authority.
- Test every match status and an ambiguous invoice link.
- Complete production permissions and certificate ownership.
- Keep invoice matching and payment approval as separate decisions.