The PO Ran Out Before the Job Did

The purchase order came with the award letter in March. PO 7731, Maple Street lift station, $48,000 for crushed stone and trucking, signed by the GC's project manager. Your office did what most offices do with a PO: wrote the number in the job folder, set it to print in the invoice header, and never thought about it again.

It worked all season. April through September, six invoices went out referencing PO 7731 and six payments came back on terms, no calls, no questions. Then the October invoice, $9,180, doesn't pay. It isn't short-paid. It isn't disputed. The GC's vendor portal shows one line of status text: exceeds PO balance. Your cumulative billing on the job reached $51,400 in a month nobody was counting, and a computer in an office two counties away declined the overage without consulting anyone.

Not one load on that invoice is in question. The tickets are signed, the quantities are right, the rates match the quote. The work is fine. The paperwork holding the money is a document from March that no longer describes the job.

Their software reads the cap. Yours doesn't

A purchase order is a credit limit, except it runs in the other direction from the one you set on your customers. They wrote it, and their accounting system enforces it with no judgment involved. GC accounting systems run some version of a three-way match: PO, receiving record, invoice. The moment your cumulative invoice lines cross the PO's face value, the match fails by arithmetic. No AP clerk decided your invoice looked wrong. The software did exactly what it was configured to do in March.

Now look for the matching control on your side. There isn't one, and the reason is mechanical, not careless. Tracking a PO burn-down takes a running total of priced work, and in most billing offices tickets don't become priced work until month end, when the tray gets keyed. The cap was actually crossed on October 14th, by one ordinary load of 57s. Nobody could have flagged it that morning, because that ticket was carbon paper in a doorpocket until the 31st. Your customer's software watched your receivable all season. Your office met the number at the same moment the rejection did.

Jobs grow. POs don't

It's tempting to file this as a fluke. It's closer to a schedule. The PO was cut from the bid quantity, and bid quantities are a floor on real jobs, not an estimate. The over-excavation where the subgrade went soft. The waste factor nobody puts in the bid. The wet spring that doubled the rock under the haul road, and the second entrance the owner added in July. Every one of those grows the tonnage. None of them amends the PO, because the growth happens on the radio between your driver and their foreman, while the PO lives in an accounting system neither man has ever logged into.

So the gap widens quietly from both ends until an invoice trips over it. And what happens next is the expensive part: your $9,180 is now waiting on another company's internal paperwork. The PM has to request a PO revision. The revision wants his change order file, which he hasn't written up, because the extra rock was a radio conversation. The change order wants the owner's signature. Plan on thirty to sixty days, with your line of credit funding all of it, and the trucks are still hauling, which means November's loads are billing against a cap that's already blown. The pile behind the bounced invoice grows every working day.

If the job wraps before the revision lands, it gets worse. The overage stops being an invoice and becomes a closeout item, argued from memory against a foreman who's demobilized, and numbers argued from memory settle toward the middle.

The balance is yours to track

Here's the claim your estimator will argue with: the PO balance is your number to watch, not the customer's, and a bounced invoice should embarrass your office, not surprise it. The pushback writes itself. It's their document, their paperwork process, and they always amend it eventually. Mostly true, and it misses where the leverage sits. A revision requested at 80 percent burned is routine: the work is visible out the PM's trailer window, the extra loads are last week's memory, and his change order is current. The same request after a rejection is a cleanup, and after demobilization it's a negotiation. The ask doesn't change. The answer does, because you're no longer asking about work anyone can see.

The manual version of the fix costs an index card per PO job: face value, billed to date, updated every invoice run, with a phone call triggered at 80 percent. Run that and you're ahead of most offices. Its weakness is the update rhythm. A card refreshed at invoicing moves in month-end steps, and a hot job can walk from 70 percent to 110 in a single cycle, which is precisely what Maple Street did.

flowchart TD
    A["PO 7731 issued: $48,000"] --> B["Tickets haul April to October"]
    B --> C{"Who watches the balance?"}
    C -- "nobody until month end" --> D["Oct 14: cap crossed by one load"]
    D --> E["Oct invoice bounces: exceeds PO"]
    E --> F["Waits on change order, then PO revision"]
    C -- "tickets priced daily" --> G["Sept 28: person sees 80 percent"]
    G --> H["Revision requested before the cap"]

Closing that gap is the slice Termco works in. Tickets get digitized the day they're written, as written, so the job's running total exists in the middle of the month instead of after it. The PO number and its face value sit in reference data on the job, and a billing rule prices each day's tickets against the running total. The load that crosses the cap trips that rule the morning it happens and gets flagged for a person to act on, while it's one phone call instead of one bounced invoice. Invoice totals assemble from the tickets that cleared. Nothing about this reaches the trucks: same books, same pens, same radio.

Find the jobs at 80 percent tonight

This one takes a legal pad and an hour. List every open job billed against a PO. Write two numbers beside each: the PO's face value, and cumulative billed plus a rough price on the unkeyed tray, ticket count times your average load if that's what you've got. Anything over 80 percent gets a call to the PM on Monday, before the arithmetic makes it for you. Then read your AR aging one more time, looking for invoices that are old, unpaid, and attached to no dispute. PO bounces hide there, filed under pending, aging politely. If you'd like outside eyes on whether your tickets could carry a running total like this, send 10-20 samples to hi@termco.ai and findings come back within 48 hours.

Every ton on the October invoice was real. Hauled, signed, priced right. The GC's computer wasn't wrong either: it kept the agreement exactly as it was written in March, and nobody told it the job had changed. People grow jobs on the radio. Machines hold caps to the dollar. Between those two facts sits whatever balance was left on the PO, and the office that checks it first decides whether the overage is a phone call or a season of waiting.