04/29/2026City CFOs, finance directors, internal audit, AP managers

Fraud Starts at Onboarding: Is Your Vendor Process Airtight?

JF

Jason F.

Co-Founder, Lunch

Fraud Starts at Onboarding: Is Your Vendor Process Airtight?

Vendor onboarding fraud occurs when a fictitious, impersonated, or compromised vendor is added to a government's vendor master file, enabling fraudulent payments that bypass standard accounts payable controls. In municipal government, it is one of the most common and costly forms of occupational fraud — and the majority of cases trace back to a single failure point: the moment a vendor record was created or modified without adequate identity verification.

This article walks through the attack patterns that exploit weak onboarding, the verification controls that prevent them, and why most government ERP systems were never designed to include those checks. If you manage or oversee vendor payments for a city, county, school district, or other public entity, this is the gap most likely to cost you money, public trust, or both.

Key Takeaways

  • Fictitious vendor schemes, ACH redirect attacks, and vendor impersonation all originate in vendor master data. If a bad record gets in, downstream controls rarely catch it.
  • Know Your Business (KYB), Know Your Customer (KYC), and anti-money-laundering (AML) checks are standard in financial services but largely absent from government ERP onboarding workflows.
  • The Association of Certified Fraud Examiners (ACFE) estimates that billing schemes — including fictitious vendors — cause a median loss of $100,000 per case (ACFE 2024 Report to the Nations).
  • Legacy ERPs like Tyler Munis, Oracle, and SAP treat vendor master management as a data-entry function, not a verification function. Modern payment platforms embed identity checks by default.
  • Strengthening onboarding is not just a fraud play — it also improves payment speed, audit readiness, and vendor experience.

The Three Attack Patterns That Start at Onboarding

1. Fictitious Vendor Schemes

A fictitious vendor is a company that does not exist — or exists only on paper — registered in the vendor master file to receive payments for goods or services never delivered. In many municipal fraud cases, the fictitious vendor is created by an insider: an AP clerk, a department head, or someone with edit access to the vendor master.

The City of Dixon, Illinois lost $53.7 million over two decades to a scheme that included fictitious vendor payments, one of the largest municipal fraud cases in U.S. history. More recently, a 2023 audit of a mid-sized Texas city found 14 vendor records with invalid or recycled EIN numbers — none of which had triggered an alert during onboarding.

Fictitious vendors succeed because most government ERPs accept self-reported data (company name, EIN, address, banking details) without cross-referencing authoritative business registries or the IRS TIN matching program.

2. ACH Redirect and Banking Detail Fraud

ACH redirect fraud — sometimes called vendor impersonation or business email compromise (BEC) targeting AP — happens when a bad actor submits a request to change a legitimate vendor's banking information. The next payment goes to the fraudster's account.

The FBI's Internet Crime Complaint Center (IC3) reported $2.9 billion in losses from BEC in 2023, with government entities among the most targeted sectors. In a typical municipal scenario, a fraudster sends an email appearing to come from an existing vendor, attaching a new W-9 and bank account details. If the AP team updates the vendor master without verifying the request through an independent channel, the redirect succeeds.

This attack does not require any insider access. It only requires that the city's vendor update process lacks out-of-band verification — a phone call to a known number, a check against a verified banking record, or an automated bank account ownership confirmation.

3. Vendor Identity Theft and Shell Companies

In this pattern, a real business's identity is stolen — its EIN, registered agent name, or state incorporation details are used to register as a vendor. Alternatively, a shell company is incorporated specifically to win a contract or appear on a vendor list, then dissolved after payments are collected. These schemes are harder to detect because the entity appears legitimate at first glance.

The Government Accountability Office (GAO) found in a 2022 report that federal agencies made an estimated $247 billion in improper payments in fiscal year 2022, with vendor identity gaps cited as a contributing factor. While local governments operate at smaller scale, the proportional risk is often higher because controls are thinner.

A KYB/KYC/AML Primer for Government Finance

Know Your Business (KYB), Know Your Customer (KYC), and Anti-Money Laundering (AML) are verification frameworks that originated in banking and financial services. They are required by law for banks, payment processors, and money services businesses. They are not required for government accounts payable departments — which is precisely why government AP is a softer target.

What KYB Checks Actually Verify

Check What It Confirms How It Prevents Fraud
Legal entity verification Business exists in state registry, is active, and matches the name/EIN provided Blocks fictitious vendors and dissolved shells
TIN/EIN matching IRS confirms the tax ID matches the legal entity name Catches recycled, stolen, or fabricated EINs
Beneficial ownership identification Identifies the real humans who own or control the entity Exposes insider-created shell companies
Bank account ownership verification Confirms the bank account belongs to the named entity Prevents ACH redirect before it starts
OFAC/sanctions screening Checks entity and owners against federal sanctions lists Meets AML obligations, flags prohibited parties
Address verification Confirms business operates at the stated address Catches PO-box-only entities and address reuse across multiple "vendors"

In a banking context, these checks happen before an account is opened. In a government AP context, they almost never happen at all.

Why Government Finance Should Care About AML

Cities are not banks. But cities move public money — often tens or hundreds of millions per year — through vendor payments. When a fictitious vendor receives a payment, that money enters the financial system through a channel that was not subject to the same scrutiny as a bank wire. For cities concerned about audit findings, GFOA compliance, and public trust, applying financial-services-grade verification to vendor onboarding is not overreach. It is due diligence.

For a broader look at how GFOA best practices apply to vendor payment workflows, see GFOA Best Practices for Vendor Payment: A Practical Implementation Guide.

Why Legacy ERPs Were Not Built for This

Municipal ERP systems — Tyler Munis, Oracle Cloud for Public Sector, Workday, SAP, and others — are designed to manage financial records, not to verify identities. The vendor master module in a typical government ERP is fundamentally a database table: it stores what you enter.

What Most ERPs Do

  • Accept manual data entry for vendor name, address, EIN, and banking details
  • Assign a vendor number
  • Route new vendor requests through an approval workflow (sometimes)
  • Store W-9 forms as attachments

What Most ERPs Do Not Do

  • Verify the EIN against IRS records in real time
  • Confirm the legal entity exists and is active in the state of incorporation
  • Check bank account ownership before the first ACH payment
  • Screen vendors against OFAC or other sanctions lists
  • Flag duplicate vendor records with matching EINs, addresses, or bank accounts
  • Identify beneficial owners

This is not a criticism of ERP vendors. These systems were designed for record-keeping and fund accounting. Identity verification was never part of the product requirement. But as fraud tactics evolve — particularly BEC and synthetic identity fraud — the gap between what the ERP does and what fraud prevention requires has widened into a vulnerability.

For a detailed walkthrough of how Tyler Munis handles vendor payments, see Tyler Munis Vendor Payment Guide. Similar dynamics apply in Oracle Cloud ERP deployments and Workday public sector environments.

The "Bolt-On" Problem

Some cities try to compensate by adding manual verification steps: requiring a department head to call the vendor, having AP staff Google the company, or running a quarterly vendor master review. These steps help, but they are manual, inconsistent, hard to audit, and easy to skip when the team is short-staffed or the fiscal year-end push is on. A manual Google search does not produce a verifiable audit trail.

How Modern Payment Platforms Address the Gap

A new generation of government payment platforms — purpose-built for the public-sector payment lifecycle — embeds verification checks directly into the vendor enrollment flow. Instead of treating onboarding as a data-entry task, these platforms treat it as an identity event.

Comparison: Legacy ERP vs. Purpose-Built Payment Platform

Capability Legacy Government ERP Purpose-Built Payment Platform
Legal entity verification Manual / not included Automated via business registry APIs
EIN/TIN matching Manual W-9 review Real-time IRS TIN match
Bank account ownership Not verified Automated micro-deposit or instant verification
OFAC/sanctions screening Not included Automated at onboarding and on schedule
Duplicate vendor detection Basic (name match only) Fuzzy matching on name, EIN, address, bank account
Beneficial ownership Not captured Collected and verified per FinCEN standards
Ongoing monitoring None Continuous — flags changes in entity status, ownership, or banking
Audit trail Approval workflow logs Full verification record with timestamps and data sources

Platforms like Lunch, which work alongside existing municipal ERP systems rather than replacing them, run KYB and bank verification on every vendor that participates in their early payment program. This means that when a vendor is paid through the platform — in 1-3 business days instead of 30-90+ — the city gets a verified vendor record as a byproduct of faster payment. The fraud-prevention controls are not an add-on. They are the infrastructure.

The Dollar Cost of Getting It Wrong

Fraud losses in government are difficult to aggregate because many cases go unreported or are discovered years after the fact. But the data points that do exist are instructive:

  • Median loss per billing fraud case: $100,000 (ACFE, 2024 Report to the Nations). Government and public administration had the second-highest number of fraud cases by industry in the same report.
  • BEC losses reported to the FBI: $2.9 billion in 2023 (FBI IC3, 2023 Internet Crime Report). Government agencies are explicitly listed as a top target category.
  • Estimated improper payments across federal agencies: $247 billion in FY 2022 (GAO). While local government is smaller in scale, the per-capita exposure may be higher due to thinner controls.
  • Average time to detect occupational fraud: 12 months (ACFE, 2024). In government, the median was even longer.

These are not abstract figures. For a city with a $50 million annual AP spend, even a single fictitious vendor receiving $150,000 in payments over a year represents a material audit finding, a potential news story, and a breach of fiduciary duty.

Building a Stronger Onboarding Process: Practical Steps

Even before adopting a new platform, finance leaders can reduce onboarding risk with targeted process improvements.

Immediate Actions (No New Technology)

  1. Separate vendor creation from vendor payment. The person who adds a vendor should never be the same person who approves payment to that vendor.
  2. Require independent verification of banking details. Before activating ACH for a new vendor — or updating banking details on an existing one — call the vendor at a phone number obtained independently (not from the request itself).
  3. Run a quarterly vendor master review. Look for duplicate EINs, vendors with the same bank account, PO-box-only addresses, and vendors with no payment activity in 12+ months.
  4. Match W-9 data to IRS TIN records. The IRS TIN Matching Program is free and available to any payer. Use it.

Medium-Term Upgrades

  1. Adopt a payment platform with built-in KYB. Rather than building verification into your ERP (expensive, fragile), layer a purpose-built platform on top that handles verification as part of the payment flow.
  2. Implement real-time bank account verification. Services that confirm account ownership at the moment of enrollment eliminate ACH redirect risk before the first payment.
  3. Require beneficial ownership disclosure for vendors above a dollar threshold. This aligns with FinCEN's Corporate Transparency Act requirements and adds a layer of accountability.

For cities exploring how payment platforms can improve vendor management without replacing the ERP, Modernizing Municipal ERP Vendor Payment Workflow Without Replacing the System covers the integration approach in detail.

Fraud Prevention as a Side Effect of Better Payment Infrastructure

Here is the counterintuitive point: the strongest argument for adopting a modern government payment platform may not be fraud prevention at all. It may be vendor experience, cash flow improvement, and operational efficiency. But fraud prevention comes built in.

When a platform verifies every vendor's legal identity, EIN, and bank account as a condition of participation, the vendor master becomes cleaner by default. When payments flow through a system with real-time monitoring, anomalies surface faster. When the city's AP team no longer needs to manually verify banking changes, they can focus on the work that actually requires human judgment.

The result is a system where paying vendors faster — in days instead of months — and preventing fraud are not competing priorities. They are the same process.

Frequently Asked Questions

What is vendor onboarding fraud in government?

Vendor onboarding fraud occurs when a fraudulent, fictitious, or impersonated entity is added to a government's vendor master file, enabling payments for goods or services that were never delivered or redirecting legitimate payments to unauthorized bank accounts. It is one of the most common forms of public-sector fraud and typically exploits the lack of identity verification during the vendor registration process.

How does ACH redirect fraud target municipal governments?

ACH redirect fraud targets municipalities through business email compromise (BEC), where a fraudster impersonates an existing vendor and requests a change to the banking information on file. If the AP department updates the vendor master without independently verifying the request — such as calling a known contact number — the next payment is sent to the fraudster's account. The FBI reported $2.9 billion in BEC losses in 2023.

Can our existing ERP prevent vendor fraud?

Most government ERPs — including Tyler Munis, Oracle, Workday, and SAP — are designed for financial record-keeping, not identity verification. They accept self-reported vendor data without cross-referencing business registries, IRS records, or bank account ownership. While ERPs can enforce approval workflows, they do not perform the KYB, KYC, or AML checks that would catch fictitious vendors or banking fraud at the point of entry.

What is KYB and why does it matter for government AP?

Know Your Business (KYB) is a verification framework that confirms a business entity legally exists, is in good standing, operates at the stated address, and is controlled by disclosed owners. KYB is mandatory in banking but not in government AP — which is why government vendor master files are a frequent target. Applying KYB checks at onboarding blocks fictitious vendors, dissolved shells, and impersonation attempts before they enter the system.

How can cities improve vendor verification without replacing their ERP?

Cities can layer a purpose-built payment platform on top of their existing ERP to add automated KYB, TIN matching, bank account verification, and sanctions screening without disrupting current workflows. Platforms like Lunch perform these checks as part of vendor enrollment in their early payment program, giving cities verified vendor data as a byproduct of faster payments — at no cost to the city.

JF

Written by Jason F.

Co-Founder, Lunch

Jason is the co-founder of Lunch. He leads the operations and infrastructure behind how Lunch processes invoices, moves funds, and reports payments to credit bureaus.

Interested in learning more?

Lunch
1241 5TH ST. #309, SANTA MONICA, CA 90401
© 2026 Lunch Inc.· All Rights Reserved