Carrier profiles — teaching KnowDoc to read an invoice
Why every carrier hides the load number somewhere different, and the three steps that fix it.
The problem, stated by the list itself
The profile list has a LOAD # FIELD column, and that column is the whole argument for the page. Across thirteen carrier profiles there are eight different fields carrying the load number — bol_number for six of them, then shipment_id, booking_number, order_reference_number, ref_number, customer_reference_number, load_number, and po_number, one apiece. Every carrier hides the same fact somewhere else. There is no universal parser for freight invoices, only a per-carrier one.
The gaps are visible from the list
Scan the list for what's missing before you add anything new. In the filmed tenant: one carrier with no schema at all, one with no sender email set, and only one carrying a sample document. Each of those is a document that will fail later, visible now.
- No schema — Nothing tells KnowDoc how to read this carrier. Every invoice fails.
- No sender email — Mail arrives and matches nothing — the unknown-carrier failure.
- No sample — The profile was never tested against a real page.
Step 1 — name, billing domain, SOP
New Carrier opens a three-step flow. The first step takes the carrier's name, their billing domain, and a dropzone for their SOP — the standard operating procedure document that describes how they bill. The billing domain is what matches inbound mail to this profile, so it is the field to get exactly right.
The AI drafts the profile
From the SOP, KnowDoc drafts the profile rather than making you build it field by field: where the load number lives, and how each charge on the invoice maps to a charge type in your system. You are reviewing a draft, not filling a form — which is the difference between ten minutes and an afternoon.
Steps 2 and 3 — sample, then test
The second step takes a real sample document. The third runs the extraction against it and shows you what came out. Do not skip this. The test is the only place a wrong field mapping is cheap to find; after go-live it surfaces as a queue of identical flags.
The saved profile
A finished profile carries wildcard sender emails, an EDI toggle, and the fourteen standard fields extracted from every invoice. Wildcards matter more than they look: carriers bill from billing@, ar@, invoices@, and no-reply@ addresses on the same domain, and a wildcard catches all of them without you enumerating each one.
- Wildcard emails — Match every billing address on a domain, not one by one.
- EDI toggle — For carriers sending structured data rather than PDFs.
- 14 standard fields — The common set extracted from every invoice, whatever the layout.
Why this is where the big number gets fixed
The AI Agent walkthrough finds that 777 of 861 processing failures — 90.2% — come down to one cause: no carrier profile matched the sender email. This page is that fix. One profile, correctly configured with wildcard senders, retires an entire category of failure. Everything else in KnowDoc is downstream of getting this list complete.
Ready to build your own?
Start free and ship your first app in minutes — or have us set it up with you.
More guides in Carriers & AI
More resources