How fraud and dispute cases are set up in finance and ERP systems

Most ERP systems have no dedicated fraud or dispute module. The case usually lives in a separate tool: a ticketing queue, a treasury platform or the bank's own portal. The ledger carries only the money. A suspense or clearing account holds the disputed amount, and payment blocks stop further loss until the case closes.

Where the case record sits

The case record and the accounting entry are almost always in different places. Treasury or the payments team opens a case when a bank flags an unauthorized debit, when a supplier says a payment never arrived, or when a card chargeback lands. That case gets a reference number, an owner and a status. It also needs a link to the bank statement line or payment document that started it.

That link is the weak point. If the case tool holds a free-text note saying "wire to vendor, last week", nobody can reconcile it later. Good setups force the user to pick the actual payment or statement line from the ERP, or at least paste its document number into a mandatory field.

Some organizations run cases through the bank's dispute portal alone. This works for card chargebacks. It works badly for payment fraud, where internal evidence, approvals and vendor master history matter as much as anything the bank holds.

How the money is parked in the ledger

When money leaves and the claim is that it should not have, the ledger has to say so. The usual pattern is a dedicated suspense or clearing account for disputed items. The original expense or payable is reversed out, and the amount sits as a receivable from the bank, the payee or an unknown party.

This is normally a manual journal. It should go through the same approval route as any other manual entry, with the case reference in the header text so the two records can be matched. Where a recovery looks doubtful, finance books an allowance against that receivable. Waiting until the case closes is a common mistake. The balance sheet then overstates what will come back.

Customer-side disputes are handled differently. Accounts receivable usually has dispute or reason codes on the open invoice, which pause dunning without touching the ledger. Only when a credit note or write-off is agreed does an entry post.

Controls on payments and vendor data

Much of the setup is preventive, and it sits in the payables and vendor master configuration. Changes to supplier bank details should trigger a workflow that requires a second person and a call-back to a known contact. A changed bank account can also place an automatic payment block on that vendor until someone verifies it.

Once a case is open, the related vendor or employee record usually gets a manual block. Payment runs skip it. Recall requests for sent wires go through the bank, and the outcome is recorded against the case and posted as a payment adjustment when funds return.

Post-payment audit sits alongside this. Duplicate payment checks, unusual payee reports and reviews of payments made outside the normal run all feed new cases.

Recovery, write-off and reporting

When money comes back, it should clear the suspense balance directly. Cash application teams often post recovered funds to miscellaneous income because they do not know the case exists. A clear naming convention on the bank remittance and a short list of open cases shared with cash application prevents this.

When recovery fails, the write-off needs approval at a level set in the delegation of authority. The loss then moves from the allowance to an expense account. Insurance claims, where they exist, are tracked as a separate receivable.

Reporting usually means a regular aging of the suspense account, reconciled line by line to open cases. Losses and improper payments are often reported to audit committees and, in the public sector, to oversight bodies. That report should come from the ledger, traced to account balances, and should not be assembled from the case tool alone.

Questions to ask the people who run it

What staff actually do often drifts from the documented process. These questions tend to surface the gaps:

• When a bank calls about a suspicious debit, who picks up, and where do they write it down first?
• Does every open case have a matching balance in suspense, and who checks that?
• How do recovered funds get identified when they arrive on the bank statement?
• Who can remove a payment block, and does anyone review those removals?
• When supplier bank details change, is the call-back actually made, and to which number?
• Are allowances booked while cases are open, or only at closure?
• Which cases never reach the case tool because someone fixed them informally?
• What happens to a case when its owner leaves or changes role?
• Where does the figure in the loss report come from, and could anyone rebuild it from the ledger?

Where setups tend to break

The ledger and the case tool drift apart. Suspense accounts collect old items nobody owns. Recovered cash gets posted to the wrong place. Blocks stay on vendors long after cases close, and the payables team learns to override them. Each of these is a configuration and ownership question more than a software one, and each is worth checking before any redesign.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.