Image: Writing Papers by Helloquence, licensed under CC0 1.0.
Your integration roadmap lists eight carriers on EDI and a visibility provider on API. Everyone else, the two hundred carriers in the tail, the drayage operators, the warehouse that photographs a signed delivery receipt on a phone, lands in a shared mailbox that three people open every morning.
That mailbox is not a gap in the architecture. It is the architecture. Any intake design that treats email as the leftover case will spend its life running most of its volume through the path it invested in least.
The long tail was never going to onboard
The American Trucking Associations, citing US Department of Transportation figures as of June 2025, counts close to 580,000 active motor carriers registered with FMCSA that own or lease at least one tractor. Of those, 91.5 percent operate ten trucks or fewer.
Price an EDI connection for a three-truck operation: mapping, testing, a VAN subscription or an AS2 endpoint, and somebody who can work out why a 210 rejected. Set that against the revenue from one shipper. The arithmetic has never worked, and it will not start working because your roadmap says it should. Those carriers bill by email because email costs them nothing, and they will go on doing it.
Ocean is no better. The Digital Container Shipping Association published its Arrival Notice 1.0.0 standard on 1 December 2025, and the reasoning it gave was that these notices are typically distributed as PDFs by email, leading to errors, delays and costly disputes over storage, detention and demurrage. When the body representing the largest container lines has to write a standard to move one document off email, email is the incumbent interface. Publishing the standard was the right call. Getting every carrier, terminal and forwarder you touch onto it is a multi-year project, and your free time clock does not pause while that happens.
EDI does not retire the mailbox either
On the carriers that do transmit, the structured feed carries the claim and not the proof. An X12 210 gives you total weight and charges in the L3 segment, rate and charges per line item in L1, and a generous allowance of N9 reference numbers to tie it back to the 204 tender. What it never gives you is the gate ticket, the delivery receipt with an arrival time written on it in pen, the photograph of a crushed pallet, or the sentence in which the carrier explains why the truck sat for five hours.
All of that arrives as an attachment on a message, from your EDI carriers as much as anyone. The dispute you raise against a 210 travels the same way, and so does the rebuttal. An audit reading only the structured feed can confirm that a detention charge was billed. It cannot establish whether the charge is owed.
Classify the message before you open the attachment
Most intake pipelines start at the attachment. Pull the PDF, run extraction, look for an invoice number, create or update a record. That order is backwards, and it is where duplicates and orphans are manufactured.
A freight mailbox carries a small number of message types, and each one wants something different to happen:
- A new invoice for a load nobody has billed you for yet.
- A re-issue of an invoice already in your system, usually corrected after you challenged it.
- A reply on an open dispute, where the attachment is evidence rather than a bill.
- A supporting document arriving late against an invoice already queued or paid.
- Operational traffic: a quote, a tender acceptance, an appointment confirmation.
- Noise, including the messages built to resemble the first category.
The same PDF can appear in any of the first three. A corrected invoice and a fresh invoice are near identical documents, and what separates them is the conversation they arrived in. Extraction cannot see a conversation. The envelope can.
Three signals, in order of reliability
Thread headers first. RFC 5322 section 3.6.4 defines In-Reply-To and References: a reply carries the Message-ID of its parent, and References accumulates the chain back to the start of the thread. If an incoming message lists the Message-ID of the dispute Penny sent on invoice 44812, the attachment belongs to invoice 44812. That is a lookup against a stored identifier rather than a judgment call, and it holds every time the sending client follows the spec.
Sender identity second. Resolve the envelope sender and its domain to a carrier record, a SCAC and the loads currently open with that carrier. A bill from a domain with no history, on a message with no parent, referencing a load tendered to somebody else, is not a payables item simply because the layout looks like one.
Subject and body last. Useful, unreliable. Reply prefixes get stripped, subject lines get edited mid-conversation, people forward rather than reply, and some mobile clients break the chain outright. Treat text matching as corroboration for the two signals above, never as the sole basis for binding a document to a load.
| What arrives | Attachment-first intake | Message-first intake |
|---|---|---|
| Corrected invoice re-sent on the dispute thread | Booked as a second invoice; two records now compete to be paid | Matched to the original and superseded, with the dispute closed against the revision |
| Delivery receipt emailed three weeks after payment | No invoice number on the scan, so it settles in an unmatched folder | Parent message resolves the load, evidence attaches to the closed audit |
| Carrier rebuttal carrying a gate log | Filed as correspondence; the timestamps never reach the charge | Routed to the open dispute and tested against the detention claim |
| Spoofed bill from a lookalike domain | Extracted and queued, with the new remit-to detail riding along | Held at classification: no carrier record, no parent, no payment |
Penny treats the message as the unit of intake and the attachment as its payload. The three independent checks in duplicate invoices do not look like duplicates gain a fourth from the thread, and the rule in a late document should supersede rather than overwrite finally has a dependable way to know which record a late scan belongs to.
The mailbox is also where the fraud is
Highway's Q2 2026 Freight Fraud Index, released on 28 July 2026, reported 784,201 fraudulent inbound emails blocked across its network, a 48.5 percent rise on the previous quarter. Communication-based attacks, a category the report defines to include compromised mailboxes, spoofed senders, account takeovers and impersonation calls, accounted for 50 percent of classified fraud vectors, up from 42.7 percent in the first quarter. Highway sells carrier identity verification, so read the absolute counts as traffic on its own network rather than an industry census. The direction is the part that bears on intake design.
Two consequences follow. Checking the sender against a known carrier record before extraction runs turns a classification step into a fraud control, at no extra cost, because the lookup was happening anyway. And a change of remittance detail arriving as a reply must never apply itself, however convincing the chain looks. Thread position establishes that a message belongs to a conversation. It establishes nothing about who sent it.
What to do next
Take one week of traffic from your shared freight mailbox and sort it by message type instead of by attachment. Count the replies that landed on threads your system already holds an identifier for, then count how many of those replies produced a second record, an unmatched scan or a reopened dispute. That ratio is the size of the problem, and measuring it costs an afternoon.
Bring the week to a walkthrough and we will run it through Penny's intake, with the classification, the thread it resolved to and the routing decision shown on every message.