Freight Invoice Aging: How to Cut Days-to-Invoice From Ten Down to Two

Most of the ten days is not billing work. It is waiting: for proof of delivery, for a lumper receipt, for someone to notice a detention charge, and for the weekly billing run. You get down to two days by doing four things. Capture documents at the moment of delivery. Settle rates and accessorials before the truck moves. Bill every day from a queue of exceptions instead of a pile of folders. Measure the clock on every load so you can see where it stalls.

The rest of this article covers how to do each of those, and what to build if you are the person writing the software.

Define the clock before you try to shorten it

Days-to-invoice is the time from the delivered timestamp to the invoice-sent timestamp. It is not the same as days sales outstanding, and that difference matters more than most teams realize.

A standard accounts receivable aging report starts counting on the invoice date, so it cannot see the days before an invoice exists. Take a load delivered on the 1st and invoiced on the 11th. On the aging report it shows zero days old, but the cash is already ten days behind. Those ten days never appear in any report, which is why nobody tries to fix them.

So measure it directly, per load, and look at the median and the 90th percentile rather than the average. Averages hide the tail, and the tail is where the money sits.

SELECT
  customer_id,
  COUNT(*) AS loads,
  PERCENTILE_CONT(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (invoiced_at - delivered_at)) / 86400
  ) AS median_days,
  PERCENTILE_CONT(0.9) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (invoiced_at - delivered_at)) / 86400
  ) AS p90_days
FROM loads
WHERE delivered_at >= NOW() - INTERVAL '90 days'
  AND invoiced_at IS NOT NULL
GROUP BY customer_id
ORDER BY p90_days DESC;

Also run a second query for loads that are delivered but not yet invoiced. The query above leaves those out, and they are often the worst offenders.

Where the ten days actually go

The causes are boring and they repeat. In rough order of how often I see them:

1. Proof of delivery lag. The driver turns in paperwork at the end of the trip, the end of the week, or whenever they next pass the terminal.
2. Missing supporting documents. Lumper receipts, scale tickets, detention logs, signed delivery receipts with every page.
3. Rate mismatches. The rate confirmation, the TMS record, and the draft invoice do not agree, and someone has to work out which one is right.
4. Accessorials found late. Detention or a layover comes up after the fact, with no timestamps and no customer approval.
5. Batch cadence. Billing runs once or twice a week, so a clean load delivered the day after a run waits days for the next one.
6. Customer-specific rules. A required PO number, a particular portal, a reference field in the wrong place. The invoice gets rejected and the clock starts over.
7. One reviewer. Every invoice goes through the same person, and that person takes vacations.

Before you change anything, tag every late load with one primary reason code for two weeks. The distribution will almost always be lopsided, with two or three causes accounting for most of the delay. Fix those first.

Move document capture to the dock

The biggest single gain usually comes from getting the POD into the system at delivery, not days later. The driver photographs or scans the signed document on a phone before leaving the receiver, and it attaches to the load automatically.

Two details decide whether this works:

• Validate at capture, not at billing. Check that every page is present and the signature is legible while the driver is still standing there. A blurry POD found on day four means a phone call, a wait, and a resend.
• Trigger on the delivery event. When the load is marked delivered, prompt for the documents that load needs. Do not rely on someone remembering.

Settle the money before the truck moves

Every billing dispute is cheaper to prevent than to resolve.

Treat the rate confirmation as the source of truth and compare the TMS rate against it at booking, not at invoicing. If they differ, fix it while the people who agreed on the rate still remember the conversation.

For accessorials, collect the evidence as it happens. Detention needs in and out timestamps, which you can take from ELD data, geofence events, or driver check calls. Get the customer's approval or reference number at the time the charge occurs. Photograph lumper receipts on site. An accessorial without evidence is a negotiation, and negotiations take days.

Keep a requirements file per customer

Most invoice rejections are rule violations you could have known about in advance. Keep a structured record for each customer:

• Required documents
• Required reference numbers (PO, load number, shipment ID) and where each one goes
• Submission channel (portal, email, EDI)
• Invoice format expectations
• Approval rules for accessorials
• Whether split invoices are accepted

Then turn that record into a checklist the system enforces. A load cannot move to "ready to bill" until its customer's checklist passes. This takes one person's knowledge and makes it something the whole team can rely on.

Bill daily from an exception queue

Drop the weekly batch. Once documents, rate checks, and customer rules are automated, most loads are clean, meaning all documents are present, the rate matches, and there are no unapproved charges. Clean loads should go out the same day, either automatically or with a single approval click.

People only look at exceptions. Each exception gets a reason code and a named owner, so "waiting on something" always means waiting on a specific thing from a specific person.

Where a customer allows it, bill the line haul now and invoice a disputed accessorial separately. Your requirements file tells you which customers accept this. Holding a whole invoice over one line item is one of the most common ways a two-day load becomes a ten-day load.

A realistic two-day timeline

Not every load will hit two days, and that is fine. The goal is a tight median and a p90 you can explain load by load.

What to build, and what to skip

If you are building this, the core is not machine learning. It is a small state machine driven by events: delivered, documents complete, audited, invoiced, disputed. Every transition gets a timestamp. That alone gives you the measurement, the exception queue, and the audit trail.

OCR can help pull reference numbers off BOLs and receipts, but have it suggest values and require confirmation before anything reaches a customer. A wrong PO number on an invoice costs more time than typing it by hand would have.

Skip dashboards until the reason codes exist. A chart of how late you are does not help much. A list of why you are late, sorted by frequency, does.

FAQ

Is days-to-invoice the same as DSO? No. DSO measures how long it takes to collect after invoicing. Days-to-invoice measures the gap before an invoice exists. You should track both, because improving one can hide problems in the other.

Should we send invoices before we have the POD? Only if the customer explicitly accepts that. Many require the POD, and an invoice rejected for missing documents usually restarts the clock, which leaves you worse off than waiting a day.

Does factoring solve this? Not by itself. Factoring companies generally need the same documents before they fund, so the bottleneck moves to them rather than going away.

What should we fix first? Measure for two weeks with reason codes, then fix the largest cause. For most operations that is POD capture or batch cadence, but let your own data decide.

Do we need new software? Not always. A clear per-customer checklist, daily billing, and delivery-time document capture can be done with the tools many teams already use. Software makes it consistent. It does not make it possible.