An invoice dispute costs more than the time it takes to resolve. There is the staff time on both sides, the delayed payment that skews your cash flow forecast, the relationship friction with a customer or supplier, and the audit trail you have to reconstruct when the same dispute resurfaces months later during a VAT review.
Most disputes are not about bad intent. They come from mismatches — price on the invoice does not match the price on the purchase order, the VAT rate is wrong, the delivery address refers to a department that no longer exists. These are data errors, and data errors are preventable when the invoice is machine-readable from the start.
Here are the most frequent causes of invoice disputes in Swiss B2B billing and what structured e-invoicing does about each one.
Wrong or missing purchase order reference
This is the single most common cause of invoice rejection in organisations that run a formal purchase order process. The invoice arrives with no PO number, or with a number that does not match any open PO in the buyer's ERP, and the AP team cannot process it without tracking down who placed the order.
The problem with PDF invoices is that there is no standard field for a purchase order reference. Suppliers put it in different places — sometimes in the invoice number field, sometimes in a notes section, sometimes not at all. The buyer's AP team has to hunt for it manually.
In a structured e-invoice — whether PEPPOL BIS Billing 3.0 or SwissDIGIN format — there is a dedicated OrderReference field. The buyer's procurement system can populate this when raising the PO, and the supplier's system can carry it through to the invoice without any manual transcription. On receipt, the buyer's ERP validates the reference automatically. If it does not match an open PO, the invoice is flagged before it reaches the AP team's queue, not after someone has spent twenty minutes looking for the original order.
Price or unit price discrepancies
The invoice says CHF 85 per unit. The purchase order says CHF 82 per unit. The supplier updated their price list in October but the buyer's catalogue was not updated. Now there is a CHF 180 discrepancy on a 60-unit order and someone has to figure out which price is correct.
In a PDF world, no system catches this automatically. The AP clerk eyeballs the invoice against the PO, notices the difference, emails the buyer, waits for a reply, chases the supplier for a credit note or a corrected invoice, and the whole thing takes two weeks.
In a structured e-invoicing setup, three-way matching compares the invoice line-item unit prices against the purchase order automatically. The ERP flags the discrepancy the moment the invoice arrives. The AP team still has to resolve the underlying commercial question — was there a price change, or was it an error? — but the detection is immediate rather than delayed, and the resolution time is measured in hours instead of days.
Structured data also makes it easier to spot systematic pricing errors. If one supplier consistently invoices at the wrong price, the ERP's matching history shows it clearly. With PDFs, you are relying on someone noticing the pattern manually.
VAT rate or calculation errors
Swiss VAT has three rates: the standard rate of 8.1%, the reduced rate of 2.6% for food and certain other goods, and the special rate of 3.8% for hospitality. Getting the rate wrong on an invoice — standard rate applied to a reduced-rate item, or the wrong rate used for a hospitality service — creates a dispute because the buyer cannot reclaim an incorrect VAT amount.
The other common VAT error is rounding. Suppliers sometimes round the VAT amount per line and sum the rounded figures, which produces a total that differs from the correct amount by a few centimes. Depending on the buyer's ERP configuration, this can trigger a matching exception even when the underlying prices are correct.
In a structured invoice, the VAT rate and the calculated VAT amount are separate machine-readable fields (TaxPercent, TaxAmount). Your invoicing system can validate the calculation before the invoice is sent — confirming that the rate applied is correct for each line item, and that the VAT amounts are calculated consistently. Buyers' ERPs can re-run the same validation on receipt. An incorrect VAT calculation is caught at source, before the invoice enters the payment workflow, rather than being discovered when the buyer reconciles their input VAT.
The EN 16931 tax category codes — which structured formats like PEPPOL and ZUGFeRD use — make the VAT treatment unambiguous. Standard rate, reduced rate, reverse charge, and exempt all have specific codes, so there is no ambiguity about what was intended.
Wrong bank account details
A supplier updates their bank account. They send a PDF invoice with the new IBAN. The buyer's AP team updates the supplier master record manually — or forgets to, or updates it incorrectly. Payment goes to the old account. The supplier calls wondering where their money is. The buyer has to issue a recall request with their bank.
In a structured e-invoice, the payee's IBAN is a defined field (PayeeFinancialAccount/ID). An ERP integration can read this field and either auto-update the supplier master or flag a change for review. The process of keeping payment details current becomes systematic rather than dependent on someone noticing the change in a PDF and remembering to update a record.
It also works the other way: if your company changes its bank account, you can update the field in your invoicing system once and every subsequent invoice will carry the new details automatically. No risk of one customer paying the old account because they had your previous invoice saved.
Quantity or delivery discrepancies
The invoice is for 100 units. The goods receipt shows 85 units were delivered. The supplier sent a partial shipment but invoiced the full order. The buyer refuses to pay for goods not yet received.
This is a legitimate dispute — the buyer is right — but it still consumes time on both sides. With PDF invoices, neither system knows there is a discrepancy until the AP clerk manually compares the invoice against the goods receipt note.
Three-way matching in a structured ERP workflow catches this automatically. The goods receipt is recorded when the delivery arrives. When the invoice is received, the ERP compares quantity invoiced against quantity received. A partial delivery means a partial match, and the invoice is flagged for the difference immediately. The AP team can approve the matched portion and hold the remainder, or contact the supplier for a corrected invoice covering only what was delivered.
This only works reliably if the goods receipt process is consistent — partial deliveries are recorded promptly, product codes on the invoice match the purchase order line items, and the ERP is configured to handle partial matching. None of that requires e-invoicing specifically, but structured invoice data makes the matching logic far less fragile. Matching on a product code from a defined ItemIdentification field is more reliable than matching on a product description string extracted from a PDF line item.
Duplicate invoices
The supplier sends an invoice. It is mislaid in the buyer's email system. The supplier chases for payment, assumes the invoice was lost, and sends another one. The buyer's AP team processes both. The duplicate payment is discovered during a reconciliation. Now someone has to issue a refund request.
This is an embarrassing and entirely preventable problem. In a structured e-invoicing network like PEPPOL, each invoice has a unique combination of seller identifier, invoice number, and issue date. A receiving system can check for duplicates automatically on ingest and reject a second invoice with the same identifier. The duplicate never enters the payment workflow.
The same logic applies on the sending side. If your invoicing system tracks which invoices have been transmitted and received, re-sending a previously delivered invoice would require a deliberate action, not just forwarding an email again.
The common thread
Every dispute category above shares the same root cause: information that should be machine-to-machine — a PO reference, a unit price, a VAT rate, a bank account number — is instead communicated via text in a PDF and re-entered by a human on the other side. Each re-entry is a chance for a mistake, a mismatch, or a delay.
Structured e-invoicing does not eliminate all invoice disputes. Commercial disagreements — was the service delivered as agreed? was the product the right specification? — are beyond what any format can solve. But the mechanical errors, the transcription mistakes, and the process failures that make up the majority of actual AP disputes become much harder to sustain once the data flows directly between systems.
If your AP or AR team is spending a meaningful portion of their week resolving disputes, it is worth looking at how many of those disputes trace back to data mismatches that a structured format would have caught. The answer is usually most of them.