The vendor looked new and urgent. The payment looked final.

What looked normal

A new supplier was set up. An invoice came in. Payment cleared. On paper, AP worked.

Then someone looked at the dates:

  1. Vendor added — Day 0

  2. First payment — Day 3

  3. Next bill — never

That pattern is simple and risky: create fast, pay big, then disappear.

Why people should care

Real suppliers usually come back. Fake or weak ones often do not.

A rush setup plus a large first payment plus no follow-up spend is how shell vendors and one-time setups get cash out. Aging reports will not show this. You need create date, pay date, and later activity side by side.

Seven checks that catch this

These tests use vendor master, invoices, and payments— data most ERP systems already have.

  1. Paid within days of vendor create

    Flag vendors where the first payment is very soon after the vendor was added.

    Business impact: Surfaces rush setups before they look “normal.”

  2. First payment much larger than peers

    Compare the first payment to typical first payments in the same category or company code.

    Business impact: Finds big cash-outs on day one.

  3. One payment, then silence

    Vendors with a single paid invoice and no later bills or POs for a long period.

    Business impact: Highlights one-and-done suppliers.

  4. Bank details changed just before first pay

    Bank account added or changed shortly before the first payment cleared.

    Business impact: Catches last-minute payee switches.

  5. Paid with thin master data

    Payment cleared while tax ID, address, or bank fields were still blank or incomplete.

    Business impact: Stops pay-first, fix-later leakage.

  6. Blocked, then paid

    Vendor was blocked or held, then reopened, then paid soon after.

    Business impact: Flags status games around payment.

  7. Same person creates and pays

    The user who created the vendor also posted or released the first payment.

    Business impact: Shows weak split of duties on new suppliers.

Why reviews miss this

Traditional

Invoice and approval

Was the invoice approved? Was the amount in budget? That still misses create-to-pay speed.

What risk needs

Create + pay + later activity

How fast was the vendor paid, how big was the first pay, and did anyone come back?

Key takeaway

New is not the problem. New, paid fast, then gone is the problem.

How foretale.ai helps

foretale.ai checks new vendors across create date, first payment, later activity, bank changes, thin master data, block-and-reopen paths, and user roles— with clear evidence for every finding.

AP and audit teams review the riskiest new vendors first—not a random sample of invoices.

How many new vendors were paid once and never seen again?

Most companies do not know—until they join vendor create date with payment history. Continuous AI checks can surface these patterns before the next rush payment.

Request a demo