Why Duplicate Payments Still Happen in Self-Billing

When you look at high-volume accounts payable, self-billing looks like a clean process. You skip tracking down thousands of incoming supplier invoices, matching them to purchase orders, and routing them for approval. Instead, you generate the payment document directly from your own goods receipt. Payments stay predictable, and administrative drag drops off.

Yet in accounts payable recovery audits across large, well-run global enterprises, significant duplicate payments consistently turn up inside this exact workflow. Often, they add up to millions of euros.

Most finance organizations running self-billing have mature ERP setups and disciplined AP teams. Here is an evaluation of where this workflow works, where it breaks, and what happens at the boundary between systems.

What is self-billing in procure-to-pay?

Self-billing (frequently automated in enterprise ERPs as Evaluated Receipt Settlement, or ERS) is an accounts payable workflow where the buyer generates the invoice on behalf of the supplier.

In traditional Procure-to-Pay (P2P), a supplier ships goods and sends an invoice. Accounts Payable matches that invoice against the purchase order (PO) and goods receipt note (GRN) before releasing payment.

Self-billing flips that operational order:

• The buyer and supplier sign an agreement where the supplier agrees not to issue sales invoices for covered transactions.
• When goods or services arrive at the dock, the receiving team logs the accepted quantity.
• The ERP automatically multiplies the accepted quantity by the agreed PO price to create an internal settlement voucher.
• That buyer-created document serves as the official payment record for both parties and automatically schedules disbursement.

Shifting the problem to the supplier

Self-billing clears the inbox for the buyer’s AP team, but in practice, it pushes a heavy reconciliation burden onto the supplier’s accounts receivable (AR) team.

The supplier’s ERP still generates sales invoices in the background for its own revenue recognition and inventory tracking. When your payment arrives, the remittance advice lists your internal self-bill document numbers or PO lines, not the supplier’s invoice references.

Because the document numbers do not match, the supplier’s automated cash-application software cannot clear the items automatically.

An AR clerk at the supplier has to manually match every payment to open sales orders. If that discipline fails, the supplier’s system still shows the original invoice as unpaid. When that backlog grows, their credit team sends a statement or copy invoice to your AP inbox, assuming the original was lost.

That copy enters standard processing, and the duplicate payment happens.

How duplicates still happen

When you activate self-billing, the supplier stops sending you anything: no invoices, no credit notes, no revised terms. That is the whole point of the arrangement. But it also means every one of those documents that used to arrive from the supplier’s side now has to be generated, tracked, and reconciled entirely on your side, inside your own systems. Most of what goes wrong here traces back to the buyer’s side failing to pick up what the supplier no longer sends: the returns never captured, the price changes never updated, the credits never applied.

That gap opens across 5 specific areas:

• Unapplied return credits: When a delivery arrives damaged or is returned, the supplier doesn’t raise a credit note. They simply assume the return will be reflected in the next self-bill you generate. That makes the buyer solely responsible for capturing every return and reducing the self-bill accordingly, and that responsibility usually falls into the gap between inventory management (MM) and accounts payable (FI): MM records the return, FI generates the self-bill of the original receipt data, and without a deliberate link between the two, the return never reduces what gets paid.

• Post-receipt price and surcharge adjustments: If pricing is renegotiated or freight surcharges are agreed after the goods receipt is booked, the supplier doesn’t send an invoice to flag it, because that responsibility now sits entirely with the buyer. If the new terms aren’t updated in the system in time, or at all, the self-bill keeps generating the old price long after the deal changes. There’s no partner invoice to catch the gap and no duplicate to trip control. The result is straightforward overpayment, invoice after invoice, running on numbers nobody updated.

• Occasional supplier invoices entering AP: Under self-billing, the supplier isn’t supposed to send invoices at all, and most of the time they don’t. Every so often, though, an automated billing engine on their side fires anyway, or an accounts receivable clerk emails a copy for customs or internal reference. If that copy lands in an AP shared inbox or OCR intake queue, a processor who doesn’t know the vendor is on self-billing keys it in as a standard open liability. The same delivery gets paid twice: once via the receipt, and once via the stray invoice.

• The exact-match ERP blind spot: Standard ERP duplicate checks look for exact matches: identical invoice numbers, vendor IDs, and company codes. Your self-bill voucher carries an internal sequential number (like SB-40892), while the supplier’s invoice carries their billing reference (like INV-77301). Because the reference numbers do not match, standard system controls see them as 2 separate, valid transactions and clear both.

• Multi-entity and regional drift: In large organizations with multiple operating units, a supplier might be set up for self-billing in Entity A, but processed under standard invoicing in Entity B. When paperwork crosses operational borders, cross-system visibility drops and duplicates slip through.

Why we’d stop using self-billing

Section three is a list of five separate failure points, and every one of them needs its own control if you want to close it. A hard intake block at the vendor level, permanently maintained as vendors move on and off the program. Matching logic that checks PO lines, delivery dates, quantities, and amounts, because exact-reference matching was never going to catch any of this.

None of that is a project with an end date. It’s a standing function, staffed indefinitely, built to police a boundary between two ERPs that neither company fully controls. Run the numbers on what that function costs to keep alive, year after year, against what self-billing saves you. Past a certain point, the control costs more than the exposure it prevents, and you’re paying to protect a shortcut.

The version of this we see most in recovery audits is the control that exists on paper and nowhere else. The agreement gets signed, the annual reconciliation gets written into the contract, and then nobody owns it in practice. Eighteen months later the same duplicate pattern is sitting in the ledger, at the exact suppliers the agreement was meant to cover, because a policy nobody is actively running is not a control.

That’s the case for dropping it. If a workflow only stays clean by adding a second, permanent workflow to watch it, the first one was never saving you anything; it just moved the cost somewhere less visible.