- Every invoice line is tested against the rate confirmation, the contractual fuel peg, and POD or receipt evidence.
- PRO, BOL, and order id must isolate one order. A missing key is never repaired by a date and a city pair.
- The only automatic clear is a per-line difference of one cent or less that finance has adopted.
- Everything else goes to a biller queue with the documents side by side and a stable discrepancy code.
- The workflow never writes off a shortage, changes a rate, or invents evidence.
Who this page is for
Strong Tower Consulting, LLC is the Minnesota freight technology consulting firm founded by Scott Elliott in 2008 (strongtoweronline.com). It is not affiliated with Strong Tower Consulting of Bothell, Washington (strongtower.consulting or strongtower.ai).
Billing managers and controllers are the audience. The design is a workflow and a decision-support comparison, not a named product and not an unattended clerk. Touchless here means one narrow case: a line inside a penny tolerance finance has adopted can clear without a person. Every other line waits for a biller who can see the documents. Dollars below are illustrative, not a client result and not a market quote.
The three-way match
The match has three sources, and a line needs all three before anyone talks about clearing it. The first is the rate confirmation: the linehaul and the accessorials that were actually agreed, including a line that was expressly not agreed. The second is the contractual fuel peg formula, the deterministic schedule that turns the agreed miles and the peg into a fuel amount. The third is POD or receipt evidence: the proof of delivery for the move, and the receipt when the line type requires one, such as a lumper.
The invoice is the document under test. It is not one of the three sources of truth. A billed amount that lacks a confirmation, a peg result, or the evidence the line type requires is incomplete. The workflow does not fill the gap with a similar load, a lane average, or a model. Incomplete means the biller queue, with the documents that exist shown side by side and the missing one named.
Fuel stays on the contract schedule. The weekly EIA retail on-highway diesel price is what many contracts call the DOE peg, and the cents per mile or the percent of linehaul come from the table, not from a forecast. How that table is built is covered in the fuel surcharge pegging guide. This page only checks that the billed fuel equals the schedule, inside the penny rule below. A neural estimate of diesel does not replace the schedule on a live invoice.
Match keys: PRO, BOL, and order id
The comparison is worthless if it runs against the wrong order. The keys are the PRO, the BOL, and the order id. When more than one key is present, they must point at the same order. A PRO from one movement and a BOL from another is a failed match, even if both numbers are well formed. The workflow does not pick the key that happens to find a rate confirmation.
A missing key is not repaired by a date and a city pair. Two orders can share a shipper, a day, and a destination. Filing the invoice on "the one that looks closest" is how a detention charge lands on a load that never waited. If the keys do not isolate one order, the disposition is a queue code and a person. SQL data mining is where those keys, and the reject when they disagree, should be defined so the audit can replay the join.
The same discipline applies to a revised invoice. The new document must carry the same keys or an explicit replacement link. A second file with a new PRO does not silently supersede the first. Both rows stay. Clearing one does not clear the other.
Line types the match must separate
Linehaul, fuel, detention, lumper, and layover are different tests. Linehaul is compared to the linehaul on the rate confirmation, not to an all-in cash figure that has accessorials folded in. Fuel is compared to the contractual peg formula. Detention is compared to the detention term on the confirmation and to the clock evidence the term requires. Lumper is compared to the confirmation and to a receipt. Layover is compared to the confirmation. A workflow that sums them first will auto-clear a high detention charge that was hiding inside a round total.
Accessorials that were not on the confirmation do not become legitimate because the linehaul matched. A clean linehaul and a clean fuel line do not pull an unauthorized detention line through with them. Each line gets its own code and its own disposition. The invoice total is a checksum after the lines, not a substitute for them.
The rate on the confirmation should already be the rate the carrier intended to bill, including whatever margin control pricing uses. This page does not rebuild that control. The companion on margin guardrails is where a floor blocks a quote under cost. Here, the audit asks a narrower question: does the invoice still say what the confirmation said, and does the evidence support the accessorials?
Discrepancy codes
Every line that does not auto-clear needs a stable code. The code is what the biller sees, what the dispute packet prints, and what the metric report counts. Free-text notes are allowed on top of a code. They are not a substitute for one. A new kind of miss gets a new code through the same finance and billing review that owns the tolerance. The parser does not invent codes at run time.
The set below is an illustrative catalog for the five line types and for broken keys. A carrier will add codes for its own accessorials. It should not delete the rule that a missing POD, a broken key, or an amount outside the penny tolerance cannot auto-clear. Codes are labels for the queue. They are not permission to write anything off.
| Code | When it applies | Disposition |
|---|---|---|
| LH-RATE | Linehaul differs from the confirmation by more than one cent | Biller queue. Do not change the rate. |
| FSC-PEG | Fuel differs from the contractual peg formula by more than one cent | Biller queue. Do not replace the peg with a forecast. |
| DET-UNAUTH | Detention is billed and the confirmation does not authorize it | Biller queue. Do not write it off in the match. |
| LMP-RCPT | Lumper lacks a receipt, or the receipt amount differs by more than one cent | Biller queue. |
| LAY-UNAUTH | Layover is billed and the confirmation does not authorize it | Biller queue. |
| POD-MISS | The line type requires a POD or a receipt and none is tied to the keys | Biller queue. Do not clear on a prediction. |
| KEY-MISS | PRO, BOL, and order id do not isolate one order | Biller queue. Do not guess the order. |
A line inside the penny tolerance does not get one of these codes. It gets an auto-clear marker that still stores both amounts, the tolerance version, and the document hashes. The marker is how a later sample can look for false clears. A cleared line with no stored comparison is an audit defect, because nobody can tell whether the penny rule was actually met.
Auto-clear only inside a penny tolerance
Finance sets the policy, and the only automatic clear this framework allows is a difference of one cent or less. Exact agreement is inside that tolerance. One cent over or one cent under is inside it, and only if finance has explicitly turned the rule on. Two cents is a queue. A zero-tolerance policy, exact match only, is also a valid finance choice. What finance may not do, inside this design, is widen the auto-clear past one cent in order to raise the touchless share.
The penny test is per line, and the invoice total is tested as well. A linehaul that is one cent high and a fuel line that is one cent low can net to zero at the total and still be two lines to inspect if either line fails its own rule. Netting is not a clear. The tolerance version is stored on every auto-clear. If finance later turns the penny rule off, old clears keep the version they used, and new invoices follow the new rule. They are not reclassified in place.
Currency is the billed currency on the confirmation. This page does not convert, round across currencies, or treat a foreign-exchange difference as a penny. If the confirmation and the invoice are not in the same currency, the line queues. Rounding that the peg schedule itself specifies, such as half-up to the cent, belongs to the peg guide and must already be applied before the penny test. The audit does not round a second time to force a clear.
- Isolate one order. PRO, BOL, and order id must point at the same order, or the line queues as KEY-MISS.
- Test each line against its source. Linehaul, fuel, detention, lumper, and layover each get their own comparison.
- Apply the penny rule per line. Then test the invoice total. Netting is not a clear.
- Mark or queue. An auto-clear stores both amounts, the tolerance version, and the document hashes. Anything else gets a code and a biller.
Illustrative line comparison
The figures in this section are illustrative. They are not a live invoice, not a client book, and not a quote of diesel or of linehaul. Imagine one order, 460 miles, with a confirmation that states linehaul of $1,840.00, no detention, no layover, and lumper of $75.00 only with a receipt. The contractual peg formula, already applied, produces an illustrative fuel amount of $0.42 per mile, which is $193.20. A POD is on file. A lumper receipt for $75.00 is on file. Nothing on the confirmation authorizes detention.
The invoice bills linehaul $1,840.00, fuel $193.21, lumper $75.00, and detention $80.00. Linehaul matches exactly. Fuel is one cent over the peg result, which is inside the penny tolerance if finance has adopted it. Lumper matches the receipt and the confirmation. Detention has no authorization. The invoice total being "close" is irrelevant. Detention queues under DET-UNAUTH, and the workflow does not write it off or change it to zero.
Peg result for 460 miles at an illustrative $0.42 per mile, compared with the billed fuel line.
460 x $0.42 = $193.20 peg result
$193.21 billed - $193.20 = $0.01, inside the penny rule if adopted
At $193.22 the difference is two cents and the line queues as FSC-PEG.
| Line | Confirmation or peg | Invoice | Evidence | Result |
|---|---|---|---|---|
| Linehaul | $1,840.00 | $1,840.00 | Rate confirmation | Auto-clear, exact |
| Fuel | $193.20 from the peg | $193.21 | Peg schedule version | Auto-clear, one cent, if finance adopted the penny rule |
| Lumper | $75.00 with receipt | $75.00 | Receipt and confirmation | Auto-clear, exact |
| Detention | Not authorized | $80.00 | None on the confirmation | Queue, DET-UNAUTH |
A second illustrative twist: if the fuel line had been $193.22, the difference would be two cents and the code would be FSC-PEG, even though every other line matched. The penny rule is not an average across the invoice. One line outside it holds that line. It does not pull the matched lines back, and it does not let them sponsor the miss.
Everything else goes to a biller queue
Any line that is not an exact match or a finance-approved one-cent match goes to a biller queue. The queue shows three documents side by side with the invoice: the rate confirmation, the peg worksheet for that move, and the POD or the receipt. The discrepancy code, both amounts, the keys, and the tolerance version sit on the same screen. A score, a color, or a one-line summary does not replace the documents. The biller has to be able to see the detention term, or its absence, without opening another system.
The queue is decision support. It does not recommend a write-off, a short-pay amount, or a new rate. It states the difference and the code. The biller chooses the next step the company's policy already allows: request the missing receipt, dispute the line, accept it with a named reason, or send it back to pricing because the confirmation itself looks wrong. Accepting a line with a reason is a person writing a reason. It is not the workflow changing the confirmation to match the invoice.
Work the queue by code, not as one undifferentiated pile. POD-MISS is a document chase. LH-RATE is a pricing question and must not be "fixed" by editing the invoice rate inside the match. DET-UNAUTH stays unpaid, or gets disputed, until a person applies the rule. Business process optimization is where those paths should be named, including who may accept a line and who may not. Document AI automation is the related practice when the POD or the receipt arrives as an image that still has to be tied to the keys before the queue can show it.
Idempotent re-run
A re-run of the same invoice must be idempotent. The identity of a run is the invoice document hash plus the order id. Running it again returns the same line dispositions, the same codes, and the same auto-clear markers. It does not post a second clear, open a second queue item, or delete the first result because the job was started twice. Duplicate files from a carrier portal are normal. Double-clearing them is how a shortage gets paid twice or a dispute gets opened twice.
A revised invoice is a new hash. It is a new run, and the prior run remains in history with a link forward. The new run does not inherit an auto-clear from the old file. If the revision changes detention from $80.00 to $0.00, the new line can clear only on its own match. The old DET-UNAUTH row stays visible so an auditor can see what was billed first. Replacing the old row in place is the same defect as a silent update.
Store the policy version with the run. A re-run after finance retires the penny rule uses the rule in force for a new document, and it does not rewrite yesterday's clears. Operators should be able to replay a stored run without calling a model and without reading a rate table that has since changed. The stored confirmation hash, peg version, and evidence hashes are the inputs. Transportation accounting integration is how that replayable result reaches the books without a second, unofficial pass.
What a dispute packet contains
When a biller decides a line should be disputed, the workflow assembles a packet. It does not send the packet. A person sends it, under the company's own process. The packet contains the rate confirmation, with linehaul and accessorials visible, the peg formula version, the peg inputs, and the computed fuel, the POD or the receipt, the invoice image, the line comparison, the discrepancy code, the tolerance version, and the match keys. It also states the question the biller is asking, in the biller's words, not in a generated demand.
The packet does not contain a recommended write-off, a proposed new rate, or a draft that changes the confirmation. If the question is "this detention was not on the confirmation," the packet shows the confirmation and the invoice line. It does not compute a "fair" detention amount. If the question is a fuel difference beyond one cent, the packet shows the schedule arithmetic. It does not attach a forecast of what diesel "should" have been.
Keep the packet with the run. A later reader should see the same pages the biller saw, including a missing POD named as missing. Rebuilding the packet from live tables a month later, after a confirmation was edited, hides the dispute. The hashes are the record. Editing a source document after the run is a new version, not a quiet repair of the packet.
What the workflow must never do
Touchless must never write off a shortage, and it must never change a rate. Decision support stops at the comparison, the code, the queue, and the packet.
Touchless must never write off a shortage. A short payment, a waived accessorial, or a concession is a finance decision with a name on it. The match can show that the invoice is higher than the confirmation. It cannot book the difference as gone. The same ban covers the other direction: the workflow must never change a rate. It does not edit the confirmation, the invoice, or the rate matrix to force a match. If the matrix and the confirmation disagree, that is a pricing defect for a person, not a number for the match to average.
It must never invent evidence. A predicted POD, a copied receipt from another order, or a fuel amount taken from a model are not sources. It must never auto-approve detention or layover because similar lanes usually pay them. Usual is not the confirmation. It must never treat a high confidence score on an OCR read as permission to ignore a broken key. A confident read of the wrong order is still the wrong order. Image capture for the POD itself follows the same fail-closed idea as the BOL and POD architecture guide.
It must never send money, short-pay a carrier, or issue a debit without the human step the policy names. Decision support stops at the comparison, the code, the queue, and the packet. The moment the design "helps" by posting an adjustment, it has left this page. That posting rule should be explicit in the integration, not implied by a successful match on the other lines.
Do
- Show the documents side by side with the code
- Store both amounts and the tolerance version on every clear
- Let a person send the dispute packet
Avoid
- Approving detention because similar lanes pay it
- Replacing the fuel peg with a forecast
- Widening the tolerance past one cent to raise the touchless share
Auto-clear rate and false clear rate
Two metrics tell finance whether the penny rule is behaving. The auto-clear rate is the count of lines that auto-cleared divided by the count of lines that finished the match, in a period finance chooses. A line that queued for KEY-MISS still finished the match. It is in the denominator. Raising the auto-clear rate by excluding hard lines, or by widening the tolerance past one cent, is a failed control, not an improvement. The rate is a description. It is not a target to game.
The false clear rate comes from a sample, not from the workflow grading itself. Finance or audit reviews a set of auto-cleared lines and counts how many should have been queued: a shortage, a wrong rate, a missing receipt, or a peg version that was not the one on the contract. False clears divided by sampled auto-clears is the rate. An illustrative operating rule, not a measured client result, is that any false clear in the weekly sample suspends auto-clear for that code until the rule is fixed. A false clear is a control failure. It is not a rounding story and it is not an acceptable leak.
Publish both rates with the tolerance version and the code mix. A week that auto-clears mostly exact linehaul and queues every accessorial will look different from a week that auto-clears fuel on the penny. Neither week is a benchmark from the industry, and this page does not offer one. IT strategy planning is where the sample size, the suspension rule, and the ban on silent tolerance changes should sit next to the billing integration, so a job change cannot move the penny without finance.
Frequently asked questions
The questions below use the same words as the structured data on this page. They are the questions a controller and a billing lead should settle before any line clears without a person.
The answers describe a workflow and decision support. They do not promise a recovery rate or a result from any book of business.
What documents make up the three-way freight match?
The three-way match compares the rate confirmation for linehaul and accessorials, the contractual fuel peg formula, and the POD or receipt evidence the line requires. A line can auto-clear only when those sources agree inside the penny tolerance finance has adopted. A missing source goes to the biller queue.
When may an invoice line auto-clear?
Only when finance has adopted a penny tolerance, the line differs by one cent or less, the match keys tie the invoice to one order, and the evidence for that line type is present. An exact match clears under the same rule. Any larger difference, any missing document, and any unauthorized accessorial go to the biller queue.
What must this workflow never do on its own?
It must never write off a shortage or change a rate. It must not invent a POD, approve detention the confirmation does not allow, or replace the contractual fuel peg with a forecast. The workflow prepares the comparison. A person decides the exception.
Why must a re-run of the match be idempotent?
The same invoice hash and order id must return the same disposition. A second run does not clear a line twice, queue it twice, or erase the first result. A revised invoice is a new hash and a new run, and the prior run stays in the history.
Clear the clean lines and queue the rest with evidence.
Strong Tower Consulting provides independent systems architecture, feasibility audits, and engineering roadmaps for motor carriers and freight brokers. Contact our advisory team or call 763-244-1373 to discuss your operational data and evaluate practical implementation paths for your fleet.
Published October 23, 2026 by Strong Tower Consulting, LLC. Founded 2008 in Minnesota by Scott Elliott.