Relay Payments Partners with Platform Science to Integrate Digital Freight Payments into Fleet Management Ecosystem

The Analysis

On 11 June, Relay Payments and Platform Science said they are putting Relay's digital payment rails inside Platform Science's in-cab Virtual Vehicle marketplace. That is the tablet a driver already has in the truck for electronic logging device compliance and dispatch. After the integration, he can authorize, process and track fuel, lumper and other over-the-road payments on the same screen he uses to know where he is going. The release hangs two numbers on the story: an estimated 40 percent of over-the-road transactions in this industry still run through cash or a paper check, and the prize both companies are positioning for is the 800 billion dollars a year that American trucking spends.

I am not going to argue about whether payments belong in the cab. Of course they do. The dash is already a terminal, and a payment button on it is not the controversial part. The question worth your time is narrower and harder: which queue does this shorten, and which queue does it leave exactly as long as it was? Get that wrong and you will staff for the wrong bottleneck for two quarters.

Here is the model I would put on the whiteboard. An over-the-road payment is a job moving through a queue. It gets created, it waits for authorization, it gets captured, it settles, it gets reconciled against a load, and it closes. Six stations, one job. The news touches two of them. Most of the money sits in the one it leaves alone.

Strip the framing and three things are true. A driver and a fleet manager can authorize, process and track fuel, lumper and other over-the-road payments from the same in-cab tablet already used for electronic logging device compliance and dispatch, so a separate payment card or a separate payment app comes off the dash. Roughly 40 percent of over-the-road transactions in this industry are still estimated to involve cash or a paper check. And the two companies are positioning for a share of the 800 billion dollars a year that American trucking spends. That is the whole payload. Everything else in the release is tone.

So build the funnel. A request goes in: somebody decides a payment needs to happen, at a fuel desk, on a scale, at a warehouse door for a lumper. Then authorization: does the funding exist, is this spend allowed, is this driver allowed to spend it. Then capture, where the money actually moves. Then settlement, where funds clear between the fleet, the merchant, and whoever is fronting the card. Then reconciliation, where this debit has to be matched to a load, a driver, a cost code, a customer, a day. And finally close, where the record is filed, the cost is billed or absorbed, and the audit trail is frozen. Six stations, and the interesting thing about a funnel is that only one of them sets the throughput. Speed up any other station and you do not move more jobs through the system. You move more jobs to the station in front of the constraint, where they wait.

Now ask which stations the integration touches. It collapses the request, because the request happens where the driver already is. It speeds authorization, because the check can ride the same session as the dispatch data. It removes a physical card from capture, which is a convenience for the driver and a real reduction in the fraud surface for the carrier. What it does not touch, on its own, is reconciliation. And reconciliation is where a payments team actually spends its hours, and where the exceptions live.

Here is the sentence from the release I would underline: eliminating the need for separate payment cards or apps. Read it as an engineering claim rather than a marketing one. Removing a card is a request-and-authorization claim. Reconciliation does not run on a card. It runs on the data that travels with the money: which load, which cost code, which driver, which customer, which day. A payment authorized on a tablet and settled without a load identifier is a payment somebody will be matching by hand next month, with a receipt, in a spreadsheet, at month-end. You did not delete that job. You moved it, and you made it arrive faster.

This is the queue law that operations people learn the hard way. If you speed up a station upstream of the constraint, you do not ship more jobs through the system. You build a taller pile of unfinished work in front of the constraint, and the pile still has to be worked by hand. Worse, it now arrives with less context, because the capture step no longer leaves a paper trail a clerk can read. I have watched a payments team digitize the easy end of the funnel and end up with more month-end overtime than before, not less, for exactly one quarter, until they automated the match. The first quarter is the trap, and the trap is invisible in a demo, because a demo shows you the tap and never shows you the month-end.

So which number should you believe, 40 percent or something smaller? The 40 percent is a share of transactions, and transactions are not dollars. Cash and paper checks do not distribute evenly across the spend. They concentrate in the small, awkward, off-hours items: a lumper who wants cash at two in the morning, a scale fee, a parking charge, a small handoff at a dock, a repair on the road. If cash and checks live in the small tickets, then 40 percent of the count can be a much smaller share of the value. Two teams will size the same project with two different answers, and the one who used the count will overstate the prize by a wide margin.

Let me make that concrete with an explicit set of assumptions, and I want you to substitute your own. Assume a mid-size carrier spends 24 million dollars a year on over-the-road items: fuel, lumpers, tolls, repairs, parking. Assume the industry figure of 40 percent of transactions applies to this fleet as a count share. Assume the average cash or check ticket is 250 dollars and the average electronic ticket is 900 dollars, because the big fuel tickets are already on cards and what is left on paper is small. Solve it. Paper is 40 percent of the count and electronic is 60 percent.

Twenty four million dollars of spend then equals 640 dollars times the total number of transactions. Divide: 24,000,000 divided by 640 is 37,500 transactions a year. Paper is 40 percent of that, 15,000 transactions at 250 dollars, which is 3.75 million dollars. Electronic is 22,500 transactions at 900 dollars, which is 20.25 million. Check the share: 3.75 million out of 24 million is 15.6 percent. There it is. Forty percent of the transactions, under these assumptions, is under sixteen percent of the dollars.

That is the first correction. The headline tells you the size of the pile, not the size of the money. Now price the pile. Assume a cash or check transaction carries 12 dollars of avoidable internal cost that an electronic one does not: issuing an advance, chasing a receipt, keying it in, matching it, funding the float behind it. Fifteen thousand transactions times 12 dollars is 180,000 dollars a year. Add the float. Assume this fleet keeps 500,000 dollars of driver advances outstanding on an average day, and assume a cost of capital of 7 percent, which is 35,000 dollars a year to stand behind that float. Total identified: roughly 215,000 dollars, on a 24 million dollar book. That is about 0.9 percent of the spend.

Now put that next to the headline. The 800 billion dollar prize is an industry total. The 215,000 dollars is your line. If you walk into a budget meeting waving 40 percent of your spend, you will be wrong by a factor of two and a half before anyone asks a question, and somebody in finance will notice. The honest framing is smaller and far more useful: you are removing roughly 15,000 paper jobs a year and the float that funds them, and, this is the part that scales, you are trying to make every settlement arrive stamped with a load identifier so that reconciliation stops being manual.

A last word on the headline before I get to the actions, because I want to be fair to it. The 40 percent figure is doing useful work: it tells you that a large share of the industry's payment volume still sits on a manual rail, which is why a partnership like this one is newsworthy at all. The trap is not the number. The trap is treating an industry number as if it were your number. Every input above, the ticket sizes, the count share, the float, the cost of capital, is yours and only yours, and the answer moves when they move. Run the same arithmetic on a fleet whose cash tickets average 900 dollars instead of 250 and the paper share of dollars jumps and the case looks better; run it where cash is 60 percent of the count and the pile is taller and the float is longer. The method travels. The 40 percent stays in the release.

That stamped load identifier is the thing I would actually test. Ask the vendors, in writing, one question: at the moment of authorization in the cab, what fields travel with the payment, and can they be made mandatory? If the answer is load, cost code, driver, customer and date, and if those fields land in your accounting system without a human retyping them, then reconciliation automates and your project metric becomes the touchless match rate. If the answer is that the fields are optional, or that they arrive in a report you reconcile later, then you have bought a faster card, and a faster card is worth about what the 215,000 dollars above says it is worth.

Let me be specific about what that mapping work actually contains, because it is the part every project underestimates. Three artifacts. A cost-code dictionary that says what a lumper is, what detention is, what a layover is, and what an other charge is when it lands, mapped to your chart of accounts and to the carrier's codes, which will disagree with yours on day one. A joining key: some field, ideally one the carrier already puts on the load, that lets the system tie a payment to a shipment without a human. And an exception taxonomy: a defined list of the ways a payment can fail to match, with a rule and an owner for each.

When a payment has no load, who calls the driver, and how long until the record is either matched or written off? That last rule is what stops the exception pile from becoming a permanent department. Build those three artifacts in month one and reconciliation has a chance to automate. Skip them and you have digitized the front of the funnel and staffed the back of it, which is the expensive way to do this.

Now flip to the side of the trade most of my readers actually sit on. You are not the fleet. You are the shipper paying the fleet. Why should an in-cab payment integration matter to you? Because the payments that go wrong in the cab are the ones that come back to you as invoice lines. Detention. Layover. A lumper your carrier hired. A re-billed parking fee. When those charges were paid in cash by a driver, they arrive at your AP desk as a photograph of a receipt or a one-line note, with no structure. Your team then either pays it and hopes, or disputes it and burns a cycle. Neither one is a decision. Both are guesses with a timestamp.

So run the same count-versus-dollars logic on your own book. Assume a shipper spends 10 million dollars a year on truckload freight. Assume accessorials, meaning detention, lumper and layover, are 8 percent of that, so 800,000 dollars. Assume 40 percent of the accessorial transactions arrive unstructured, at an average of 180 dollars, and the structured 60 percent average 420 dollars. Total accessorial spend then equals 324 dollars times the number of accessorial transactions, so 800,000 divided by 324 is about 2,469 line items, of which 988 are unstructured, worth about 178,000 dollars. Now cost the unstructured ones. Assume six minutes of AP time each at 45 dollars an hour, which is 4.50 per item, so about 4,450 dollars, plus an audit-leakage assumption of 1.5 percent of the unverifiable amount, about 2,670 dollars. Call it just over 7,000 dollars a year on a 10 million dollar book.

Seven thousand dollars. I want you to feel how small that is, because the temptation with a story like this one is to promise a jackpot, and the jackpot is not there in the direct arithmetic. On a mid-size shipper book, the cash savings from digitizing over-the-road payments are a rounding error next to the freight bill. So do not buy it for savings. Buy it, if you buy it, for the audit trail and the dispute record: the ability, when a carrier re-bills a 900 dollar detention you never authorized, to pull the load-level payment record in one query and settle the argument in an hour instead of a week. That is a control purchase, not a cost purchase, and it should be justified on the page as one.

There is one more lever on the shipper side, and it is a contract lever rather than a software one. If unstructured accessorials are expensive to process, you can make them expensive to send. Put an itemization requirement into the carrier agreement: any re-billed accessorial above a stated amount must arrive with a load number, a date, a cost code and a receipt, or it is not payable in the standard cycle. That one clause turns a payment-integration question into a documentation question, and documentation is free to require. It does something subtler too. It makes the carriers who already keep clean payment data your preferred carriers, which is the right incentive, and it puts the ones who run on cash on a schedule to clean up or to price the friction. You do not need the technology to start this. You can start it in the next tender.

How long before any of this shows up? Weeks to a quarter for the plumbing, longer for the benefit. The cab integration can be live on a pilot group of trucks in a few weeks. The reconciliation gain cannot show up until the mapping between payment records and load records is built and tested, and that mapping is data work: a joining key, a cost-code dictionary, a rule for what happens when a payment has no load. Realistically, expect the first month to look identical to the last month, expect months four to six to look different, and only if the mapping was built in month one. If somebody promises you a faster month-end close in the very first cycle, ask them what the join key is. The answer is usually silence, and the silence is the honest part of the conversation.

For a pilot, I would run it as a shadow, not a race. Thirty days, one fleet or one lane, with the system authorizing and recording while the old process still runs in parallel, and a weekly read on three numbers: touchless match rate, exceptions per thousand settlements, and the 95th percentile settlement cycle in days. Running two processes side by side is annoying, and it is the only way to see the exception population before it becomes your whole month-end. Set the threshold before the pilot starts, not after it ends. A project earns a rollout if the touchless match rate clears 95 percent and the exception rate falls for four consecutive weeks; if the match rate plateaus, the join key is wrong, and no additional feature will fix a wrong join key. That is the whole test, and it costs one lane and one month.

What would make me wrong? Three conditions, and any one of them flips the conclusion. If your settlement data is already clean, if your carrier or your 3PL already sends a load-level remittance file your system auto-matches, then the cab integration buys you a nicer capture experience and almost nothing at the constraint, and the match rate is not the metric because it is already high. If your fleet runs mostly on owner-operators who use cash by habit and by tax practice, then this is a behavior change wearing a systems costume, and behavior changes fail at a rate no integration release will ever quote you.

And if your real pain is not reconciliation at all, if it is fraud at the point of capture, a card skimmed at a truck stop, then a capped, in-app, driver-bound authorization is worth more than a faster one, and the thing to test is whether the payment can be tied to a specific driver session rather than to a physical card. Different bottleneck, different tool. The release does not tell you which bottleneck you have. Your own logs do.

So the quarter's work is not a procurement decision. It is a measurement decision. Pull twelve months of over-the-road payment records. Split them into paper and electronic. Count them by ticket size, because the count and the dollars will disagree and you need both on one page. Build the join key between a payment and a load. Measure your touchless match rate as it stands today. Put a single number on your float. Do that and you will know, without a demo, whether this class of integration is worth anything on your book, and you will be carrying the two or three numbers that decide it. That is the only version of this story where you are not guessing.

↑ Back to the key points

— By Ravi Chandran