A company moves domestic truckload freight, international ocean shipments, and small parcel orders. Each generates transportation charges, but the documents, rate structures, timing, currencies, and exceptions differ. If the audit treats them as variations of the same invoice, it may flag too much routine work and miss the differences that matter.
A freight audit program needs consistent financial control. It also needs to understand the business it is controlling. That includes how shipments are planned, which contracts apply, what evidence is available, who approves exceptions, and how validated costs reach the right account and payment process.
The question is not whether a program is called “custom.” It is whether its rules and workflows reflect the shipper’s actual transportation decisions and financial obligations.
Start with the traffic, not the invoice template
An invoice is the last expression of decisions made earlier. The shipment’s mode, service, origin and destination, size, route, provider, terms, and delivery events determine which charges might be valid. A useful audit design begins with that traffic profile and the contract language governing it.
For one customer, the hard problem may be parcel charges spread across thousands of accounts. Another may need to validate complex accessorials on a limited number of high-value ocean shipments. A third may have multiple legal entities and local payment requirements. A standard set of checks can provide a foundation, but the material risks and available evidence differ.
Map shipment volume and spend by mode, provider, region, business unit, and charge type. Identify the contracts, effective dates, exceptions, and supporting documents that each group requires. Then decide which checks can be automated consistently, which need a tolerance or approval, and which require expert review.
The same charge can require different context
Consider detention. On one lane, the agreed free time may be tied to a delivery appointment. On another, it may begin when the transportation provider checks in. The contract might define exclusions or require particular documentation. A flat rule applied to both lanes will either challenge valid invoices or allow unsupported charges through.
The relevant records can also differ. A facility may maintain appointment and gate timestamps, while a remote delivery relies on provider documents. The audit needs to know which source is authoritative for that transaction and what to do when the evidence conflicts or is missing. It should not silently treat an absent timestamp as proof that a charge is invalid.
This example is about the structure of the control, not a claim that every detention charge can be eliminated. A well-designed audit confirms the correct terms and supporting facts. A recurring valid charge may then point to an operational question beyond invoice accuracy.
Design the program around five practical differences
| Difference | Questions for the audit design |
| Modes and services | Which attributes, rate structures, and documents determine a valid charge for each traffic group? |
| Contracts and rates | How are terms versioned, applied by effective date, and updated after negotiation? |
| Data sources | How do invoices, shipment records, provider events, and supporting documents arrive and match? |
| Exceptions and approvals | Which variances are routine, which require a specialist, and who has authority to approve them? |
| Financial settlement | How are currencies, local practices, allocation, payment, and ERP posting handled? |
The answers should produce a documented control design, not a separate ad hoc process for every invoice. Shared standards for identifiers, audit trails, security, and accountability help the organization govern the whole program. Configured rules handle genuine differences in terms and workflow.
Data quality sets the ceiling on audit quality
A sophisticated rate rule cannot validate a shipment reliably if the invoice lacks the correct provider, account, weight, service, or reference number. Many organizations receive transportation information through EDI or API, email, PDFs, portals, spreadsheets, and other channels. The design must account for what arrives from each source and how it becomes a usable transaction record.
Capture and extraction are only the beginning. The program needs to classify, match, enrich, and validate the information against reference data and supporting documents. When a field is uncertain, the workflow should preserve that uncertainty for review rather than manufacturing confidence. Duplicate detection and business rules can catch issues early, but their effectiveness depends on consistent identifiers and current master data.
A useful discovery exercise takes a representative sample from each significant traffic group. Which fields are present? Which are trustworthy? Where do identifiers fail to match? What manual work is needed before the invoice can be audited? This often reveals a different implementation priority from the one suggested by invoice volume alone.
Global consistency still needs local financial reality
A global shipper may want one view of transportation spend and one standard for financial control. That does not mean every country or entity should use an identical payment workflow. Currency, tax treatment, bank requirements, local business practices, and documentation may differ.
The program should define what is common such as data definitions, approval accountability, audit history, and reporting measures and where local configuration is required. Finance should know which entity owes the amount, which currency and tax fields apply, who approves it, and how the validated obligation is posted. A consolidated dashboard is more useful when those differences remain visible beneath the totals.
Local variation should be governed rather than hidden. A rule change for one country or mode should have an owner, an effective date, and a way to test that it does not disrupt another part of the program.
Use exceptions to test whether the design fits
A program that sends nearly every invoice to manual review may have rules that are too rigid, insufficient source data, or contracts that have not been translated accurately. A program with very few exceptions may be efficient, but its controls still need to be tested against known difficult cases. Neither a high nor a low exception rate proves quality by itself.
Review exception reasons by mode, provider, facility, and contract. Separate genuine billing discrepancies from missing documents, reference-data mismatches, approval needs, and valid operational charges. Measure first-pass processing, correction rates, active handling time, and repeat exceptions. Sample transactions that passed automatically as well as those that were challenged.
If a pattern recurs, change the component that caused it. That may be the provider’s data feed, a contract mapping, a rate rule, an approval threshold, or a shipment process. Configurability is valuable when it makes a specific control more accurate or reduces unnecessary work without weakening governance.
Choose the capabilities the problem requires
Freight audit and payment can remain the center of the program while other capabilities address the conditions around it. A rate or pricing engine may be important where contracts are complex. Transportation management context may clarify routing, tender, and service choices. Claims processes may need shipment-linked documentation. Analytics may help finance understand patterns across validated transactions. Some customers need several of these connections; others need a narrower scope.
The design should begin with the customer’s highest-value questions: What can we verify today? Which charges remain difficult to explain? What information is missing? Where do payments, allocations, or local processes require different controls? A phased program can address those needs in a deliberate order and test each addition against the traffic it serves.
One nVision Global, configured for the customer’s needs
At nVision Global, freight audit and payment sits within a broader transportation technology and services ecosystem. Information ingestion, data intelligence and governance, pricing and rating, audit, exception management, payment, allocation, and analytics can work together to produce a more complete transportation financial record. The configuration and connections depend on the customer’s modes, contracts, regions, systems, and agreed scope.
This is the basis for Transportation Financial Intelligence™: validated costs linked to enough operational and financial context to explain what happened and support the next decision. A good freight audit program should reflect how the customer actually ships and pays, while giving leaders consistent control over the results.
Frequently Asked Questions
What makes a freight audit program configurable?
Its rate and audit rules, data mappings, tolerances, exception routing, approvals, allocation, payment, and reporting can be set to reflect the customer’s contracts and operating requirements. The scope and feasibility depend on the available data and implementation design.
Does every mode need a separate freight audit process?
Not necessarily. Common governance and financial controls can span modes, while mode-specific terms, shipment attributes, documents, and exceptions are handled by appropriate rules and workflows.
How can a shipper tell if its audit rules do not fit?
Review repeated manual work, recurring false exceptions, missed discrepancies, incomplete documents, and charges that cannot be linked to contracts or shipment events. Validate both challenged and automatically approved invoices.
Where should a company begin?
Profile the traffic and select representative invoices from the most material or difficult groups. Map their contracts, data sources, audit questions, exception owners, and financial posting requirements before deciding what to configure first.