Purchase Order Automation Through a Tendering Waterfall: How We Designed Carrier Selection for a Specialty Hardware Distributor
- Ed Hitchcock
- Apr 21
- 7 min read
By Ed Hitchcock, Enterprise AI Systems Architect, SupplyTech Solutions
Most purchase order automation conversations start in the wrong place. They start with the PO itself, with the idea that if you generate the document faster, you have solved the problem. The PO is a trailing artifact. It describes a decision that was already made upstream: which carrier, at what rate, under what terms. If that decision is made manually by someone working a phone and an email inbox, automating the paperwork downstream is cosmetic.
This post covers one design decision from our ongoing work with a mid-market specialty hardware distributor. We built a contract-to-spot tendering waterfall that automates the carrier selection decision itself, which lets the purchase order generate automatically at the moment a carrier accepts a load. This is the second post in a series. The first covered why we consolidated three logistics channels before touching the ERP.
Why Tendering Was the Right Next Problem
Once the unified operations layer from Part 1 was in place, the data coming out of it was clean. We had a single view of contract carriers, owner-operators, and brokered capacity moving through the same workflow. What we did not have was an automated way to decide which carrier should get any given load.
The existing process was manual. A load came in from the ERP, a coordinator pulled up the routing guide in a shared spreadsheet, they called or emailed the primary contract carrier for that lane, and they waited. If the carrier rejected or did not respond in a reasonable window, the coordinator moved to the next name on the list. If the contract carriers were all out, the coordinator posted to a spot board.
The decision logic was not complicated. It was written down in the routing guide. But the execution was entirely human, and it produced three specific pain points that made purchase order automation impossible downstream.
First, tender rejections were not tracked systematically. A carrier designated as primary on a given lane might quietly reject Friday afternoon loads at a 38% rate, and nobody would see it until the quarterly review. That behavior is important. It tells you the routing guide is wrong for that day of the week.
Second, the time between load creation and carrier acceptance averaged well over an hour during peak periods. That is time the coordinator spent waiting, and time the load sat in an ambiguous state where neither the PO nor the AP side of the ERP could progress.
Third, there was no consistent audit trail of what was offered, to whom, at what rate, in what order. Disputes over whether a carrier had been offered a lane first had to be reconstructed from email threads.
Automating PO generation without first automating the tendering decision would have codified all three problems.
The Waterfall as a Design Pattern for Purchase Order Automation
The tendering waterfall is a well-understood pattern in transportation management. What was original to this engagement was how we structured it to feed the PO and AP integration points directly, so that purchase order automation fell out of the design as a byproduct rather than a separate project.
The waterfall moves a load through a prioritized list of carriers in defined steps. Each step has a time budget and a response requirement. If the carrier does not accept within the window, the load moves to the next tier automatically.
Our implementation used three tiers. Tier one was the primary contract carrier for the lane, with a 30-minute tender window. Tier two was two or three secondary contract carriers, tendered simultaneously with a 20-minute window. Tier three was the spot market, with dynamic rate posting to a curated pool of brokered capacity. Each tier had its own rate logic and rejection handling.
The critical design choice was that the waterfall itself had to own the decision, not the coordinator. The system made the offer, enforced the window, tracked the response, and escalated when needed. The coordinator became an exception handler. That shift is what made downstream PO automation possible. The PO could be generated at the moment of acceptance, because the moment of acceptance was now a defined system event, not a handwritten note on a dispatch sheet.
How the Waterfall Connects to the PO
When a carrier accepts a tender, three things happen in sequence, and all of them are automated.
The acceptance event triggers a purchase order generation against the carrier in the ERP. The PO carries the accepted rate, the lane details, the expected pickup and delivery windows, and the carrier classification from the consolidated operations layer. Because the carrier record is already structured with its payment terms, compliance status, and classification, the PO inherits all of that without any lookup or manual entry.
A dispatch record is created in the operations layer, linked to the PO. This is what the coordinator sees when they open the load. It shows the tender history, which carriers were offered the load, in what order, and what they said. That audit trail is now a first-class record rather than a reconstruction from email.
A tracking expectation is registered, with the trigger points for the AP voucher generation downstream. The system now knows that when proof of delivery is confirmed for this load, an AP voucher should post automatically against this specific PO. That linkage was never possible in the manual process, because the PO did not exist until a finance clerk typed it in from a batch of paperwork days or weeks later.
This is what we mean when we talk about purchase order automation as an outcome of better upstream design. The PO is automated because the decision that drives the PO is automated. The two are the same thing.
What the Waterfall Revealed About the Routing Guide
One useful output of the waterfall was what it exposed about the existing routing guide.
The guide had been built years earlier and updated on an ad hoc basis. When the waterfall started running against it, we got clean data on tender acceptance rates by carrier, lane, and day of week for the first time. Patterns emerged quickly.
Several primary carriers had effective acceptance rates well below what would justify their primary designation. One carrier had a 38% rejection rate on Friday loads specifically. Another accepted reliably for short-haul lanes but rejected consistently on anything over 500 miles, despite being the primary on several long-haul lanes.
These patterns had existed for a long time. They were invisible because nobody was tracking them systematically. The waterfall surfaced them within weeks. The operations team used the data to rebuild parts of the routing guide. The system did not replace their judgment about carrier relationships. It gave them the evidence base they had not had before.
Handling Exceptions Without Breaking the Flow
A waterfall fails if it does not handle edge cases gracefully. We spent meaningful time on the exception paths.
If all tiers run out without an acceptance, the load escalates to a coordinator with full context: what was offered, to whom, at what rate, and what rejection reasons were given. The coordinator can take manual action, and the audit trail captures it the same way an automated step would be captured.
If a carrier accepts a tender and then cancels before pickup, the system can re-initiate the waterfall from the appropriate tier rather than restarting from the top. Restarting from the top wastes time and burns goodwill with higher-priority carriers.
If a rate negotiation is needed on a spot tender, the coordinator can intervene in the third tier without disrupting the tier one or tier two logic. Negotiation is an expected branch, not an exception that breaks the state machine.
These were not complicated features individually. They were the details that separate a waterfall that works from one that coordinators abandon.
What We Measured
The numbers we tracked during the early deployment were deliberately conservative and focused on what the system could actually prove.
Time from load creation to carrier acceptance dropped noticeably during peak periods, moving from the previous hour-plus average toward a steady state in the 15 to 25 minute range for loads that cleared tier one or tier two. Loads that reached tier three took longer by design, since spot market tendering has its own cadence.
Coordinator time spent on tender execution itself fell significantly. The coordinator's attention shifted toward exception handling, rate negotiation on complex lanes, and carrier relationship work. Across the coordination team, we estimate roughly 10 to 15 hours per week of administrative effort moved from tender execution to higher-value activity.
Tender rejection tracking became a reporting output rather than a reconstruction exercise. The client could see rejection rates by carrier, by lane, and by day of week on an ongoing basis, which directly informed routing guide updates.
PO generation moved from a next-day batch process to a real-time event tied to carrier acceptance. That alone collapsed a 24 to 48 hour delay in the financial data flow, which had been one of the primary reasons reconciliation lagged 30 to 45 days in the original state.
We are not claiming the waterfall solved everything. It solved the carrier selection decision, which is the specific problem it was designed to solve. The AP side of the integration, the lane analytics layer, and the financial integration work each have their own posts coming in this series.
Why Purchase Order Automation Requires This Sequencing
The broader point we come back to is that purchase order automation is almost always a downstream consequence of an upstream design choice. The PO is the receipt of a decision. Automating the receipt without automating the decision produces accurate-looking paperwork attached to opaque processes.
When we talk with distributors about purchase order automation, the first question we ask is: what decision does the PO document, and how is that decision currently made? If the answer involves a phone call, an email thread, or a shared spreadsheet, then automating the PO itself is premature. The decision has to move into the system first.
The tendering waterfall is one pattern for moving that decision into the system in the freight procurement context. The same principle applies to other procurement categories. Automate the decision, and the paperwork follows naturally. Automate the paperwork without the decision, and you have built a faster version of the same bottleneck.
What Comes Next
The next post in this series covers the financial integration architecture: how the PO, AP, and settlement flows connect to the general ledger without the 30 to 45 day reconciliation lag that defined the original state. The post after that covers the analytics layer we built on top of the consolidated operational data once it was flowing cleanly.
Comments