$186 billion in improper payments and the vendor master file nobody signs
Improper payments are measured retrospectively, by design, because the estimation methodology was built to size a problem rather than to stop one. Meanwhile the single field that redirects a payment stream is edited by finance staff under role permissions.
Where do improper payments actually leave?
Through the vendor master file, which is maintained as a record rather than controlled as a payment instruction. Payment integrity spending concentrates on detection and recovery after disbursement; the field that redirects money is edited through an ordinary maintenance workflow.
- GAO-26-108694 reported roughly $186 billion in estimated improper payments for fiscal 2025 across 64 programs at 15 agencies. Improper payments are not synonymous with fraud and GAO says so.
- Detection, data matching and recovery all act after the payment. Nothing acts at the moment the payee record changes.
- The categories GAO reports do not separate payee-record manipulation from eligibility error, so this article does not attribute the headline figure to either.
Part of Public sector identity
What the figure is, and what it is not
In April 2026, GAO reported that for fiscal year 2025, fifteen agencies estimated approximately $186 billion in improper payments across 64 programs — about $24 billion less than the prior year. Subsequent 2026 work addressed agency actions needed on improper payments and fraud risk in federally funded programs, and August 2026 reporting examined fraud risks across the largest state-administered programs.
GAO is careful about this and so should anyone citing it be: an improper payment is one that should not have been made or was made in an incorrect amount. That includes underpayments, documentation deficiencies and eligibility errors. It is not a fraud figure, and treating it as one is the most common misuse of the number.
Three classes of control
Payment integrity effort divides into three classes, and it is worth seeing them separately because almost all the spending is in the first two.
| Class | Examples | When it acts | What it cannot address |
|---|---|---|---|
| Eligibility screening | Income verification, death master file, enrolment checks | Before payment | Whether the payee record is correct |
| Data matching | Do Not Pay, cross-programme matching | Before or at payment | Whether an authorised human changed the destination |
| Moment-of-payment authorisation | Largely absent | At the change event | — |
| Recovery | Post-payment audit, collections | After payment | Most of the money, in practice |
The field that moves money
A vendor master record, or a payee record in a benefits system, contains banking details. Changing them redirects every subsequent payment to that payee.
In a federal or state financial system this is an administrative transaction performed by finance staff under role-based permissions, typically with segregation of duties between the requester and the approver and sometimes with a supporting form from the vendor.
The supporting form arrives by email. The approval is a workflow state. Neither is bound to the vendor's authorised official, and the agency's own segregation of duties does not address an instruction that was fraudulent before it entered the system.
What the receipt would carry
{
"type": "manav-stmt/1",
"action": "payee_banking_change",
"render": [
"Entity: [legal name, UEI / TIN]",
"From account: [full existing details]",
"To account: [full new details, unmasked]",
"Effective: [date]",
"Requested by: [name, title at the entity]"
],
"entity_official": "[credential assertion]",
"agency_approver": "[credential assertion]"
}Two signatures: the vendor's authorised official, and the agency approver. Each is verifiable offline, which means an inspector general can check them without access to the financial system — the property that makes this an audit artefact rather than another internal log.
Why recovery cannot be the answer
Recovery audit and collections are real and they recover a fraction. For diverted payments specifically, funds move quickly and frequently offshore, and the recovery window is measured in days.
That asymmetry — seconds to divert, days to detect, negligible to recover — is why moment-of-change controls dominate post-payment controls economically, and why the current allocation of effort is the wrong way round.
The Do Not Pay direction
Congressional attention in 2026 included proposals to reform Treasury's Do Not Pay system to improve agency access to payment verification tooling. That is a sound direction and it is a matching control — it checks a payment against known-bad data.
Matching cannot tell you whether the vendor authorised a change to their own banking details, because a legitimate vendor with a newly changed destination is not on any list. The two controls are complementary and only one of them exists.
What an agency can do without legislation
- Count payee banking changes per year and the payment value flowing through each changed record in the following ninety days.
- Identify the top decile by value. That is the scope.
- Require the vendor's authorised official to sign the change for that decile, with details rendered unmasked.
- Retain the receipts as audit artefacts and offer them to the inspector general as a sampling source.
Why the vendor master is treated as a record
| Treated as a record | Should be treated as |
|---|---|
| Maintenance ticket | A payment instruction change |
| Data quality exercise | A control point |
| Bulk-loadable | Individually authorised |
| Edited by data staff | Authorised by an official |
The distinction is not academic. A programme can have excellent eligibility controls and still pay a legitimate determination to an account somebody changed in a maintenance queue.
Objections and honest limits
“Improper payments are mostly errors, not fraud.” Correct, and worth repeating — the headline figure is not a fraud figure. The vendor master argument is about the fraud subset specifically, and about a control that is cheap either way.
“Recovery audits get the money back.” A fraction of it, at cost, long afterwards. Recovery is what you do when the control was upstream and absent.
Controlling the vendor master
- Reclassify banking fields as payment instructions. Out of the maintenance queue.
- Render the delta on change. Old and new, plus when it last changed and by which path.
- Require an official's signature. Not a data steward's ticket closure.
- Hold the first payment after a change. The cheapest containment available.
Terms used here
- Improper payment
- A payment that should not have been made or was made in an incorrect amount. Mostly error, with a fraud subset.
- Vendor master file
- The record of payees and their banking details, from which disbursements are drawn.
- Recovery audit
- Post-payment review to identify and reclaim improper payments, which recovers a fraction at cost.
Frequently asked questions
Is the $186 billion figure a fraud number? No. GAO distinguishes improper payments from fraud, and this article preserves that distinction. Improper payments include underpayments, documentation deficiencies and eligibility errors.
How much of it is payee manipulation? GAO's reported categories do not separate it, so nobody can say. This article does not estimate it.
Does Do Not Pay address this? It is a matching control against known-bad data. A legitimate vendor whose banking details were fraudulently changed does not appear on any list.
Would vendors participate? Large vendors already maintain authorised official records with agencies. The change is that the official signs rather than emails.
Are improper payments the same as fraud? No. The headline figure is mostly error. The vendor master argument concerns the fraud subset, and the control is cheap regardless.
Why is the vendor master the weak point? Because it is maintained as data rather than controlled as a payment instruction, and changing it redirects every future disbursement.
What is the cheapest containment? A short hold on the first payment after a banking change.
Where this fits in Manav
Manav binds the authorising official to the exact release, award or disbursement being authorised, and produces a receipt an inspector general, an auditor or another agency can verify without access to the issuing system.
Sources and further reading
- GAO-26-108694, April 2026 — agencies' estimated improper payments for fiscal year 2025
- GAO-26-108044, June 2026 — improper payments: agency actions needed
- GAO-26-109100, July 2026 — managing fraud risks in federally funded programs
- U.S. Government Accountability Office reports
- Treasury Do Not Pay programme documentation and 2026 congressional reform proposals.
- PaymentAccuracy.gov — federal improper payment data
- GAO-15-593SP — A Framework for Managing Fraud Risks in Federal Programs