A freight invoice arrives. Someone has to decide where those charges land in the general ledger.
For most finance teams that decision is manual, and it happens thousands of times a month. Coding freight invoices line by line is one of the most time-consuming tasks in logistics finance, and the work scales with shipment volume while the team stays the same size.
The usual response is to code at the invoice level. One code per invoice, applied to the total. It's fast, but it buries exactly the detail finance needs. A single truck invoice covers twelve store deliveries. A weekly parcel invoice covers thousands of packages across every channel you sell through. Code that as one transaction and every one of those distinctions is gone.
The consequences show up in three places:
While most FAP (freight audit and payment) solutions focus mainly on the audit and payment, Loop's Logistics Data Platform delivers value beyond a classic FAP solution. By building a granular, accurate data foundation, Loop has the data and intelligence to do more.
Loop’s platform extracts and structures data from logistics documents, including invoices, bills of lading, and customs paperwork, and links each charge to the shipment it belongs to. A coding rule can only read what has been captured and connected. If the shipment record doesn't carry the purchase order, no rule can identify the brand. If a charge isn't linked to a shipment, there's nothing to group charge sets around. Cost allocation is only as good as the data underneath it.
A key feature of Loop's FAP solution that takes advantage of this data is our powerful cost allocation (GL coding) feature.
Loop Cost Allocation automatically assigns GL codes, cost centers, and sub-accounts to every line item on every invoice. Due to this granularity, Loop can route linehaul charges to one GL account, fuel to another, and each accessorial to its own cost center. Line-item allocation is the only model Loop runs in production, across every client on the platform.
Once each charge carries its own code, finance and business units can see exactly which charges belong to the brand, department, and account that incurred them.
For compound accounting structures, Loop supports multi-segment codes from separate sources. A string like 2300 540140 16 0612 9001 is common in the Loop platform where clients need to capture detailed, business-specific logic. For example, this string might include a company code from the carrier, a cost center from the delivery address, and an account number for a specific charge type—all combined into one meaningful and powerful code.
Key features that differentiate Loop’s cost allocation approach from other FAP vendors include the following:
The information required to properly code a shipment or line item isn’t always found on the carrier invoice.
Loop’s coding rules read from lookup tables built around the data your business uses, with the fields each decision requires. Those tables can scale to thousands of entries and be updated by CSV or API. The result is a coding system that reflects how the business operates, not just how the carrier formats an invoice.
Impact story: Under a multi-plant manufacturer’s accounting policy, freight tied to direct materials must be capitalized to inventory rather than expensed immediately. Get it wrong and both the financial statements and product margins are distorted. Nothing on a carrier invoice says what was inside the shipment, so the coding rules read from a 67,632-entry material master, alongside supplier addresses and plant cost centers, all supplied by the company.
The capitalization decision now happens line by line, by rule, rather than by a person inferring it from a freight document. Inventory valuation and product margin reflect actual freight cost.
Because Loop’s coding logic reads from reference tables, those tables can be updated without rewriting the rule. Address matching resolves variant spellings to a canonical form, so a lookup does not fail because a carrier wrote “Ste 200” instead of “Suite 200.” When shipment data is corrected downstream, allocation re-runs automatically.
Rule changes can also be tested against historical invoices before they affect live invoices, so the impact is visible in advance.
Impact story: A multi-brand specialty retailer has two brands that share inbound containers and pool trucks to stores, so a single charge can cover goods belonging to both. Coding rules derive store-level codes and business area from the company’s own store master, a 727-row table mapping every store to its address and cost center. Brand comes from patterns in the purchase order number. As stores open and close, the master can be updated and the rule uses the current mapping. Each brand’s P&L reflects its allocated share, and regional operations can see which stores are expensive to serve.
A code tells you where a charge landed, but for most systems there’s no other information on why that code was applied.
Loop shows the information and explains the rule behind a supported allocation, along with any manual override. Finance can verify the decision directly instead of tracking down the person who configured the rule. Activity history shows who changed an allocation and when.
A large parcel invoice includes numerous decisions and data points. One recent invoice from the food producer above carried $91,833.18 in spend across 3,366 tracking numbers, 12,142 individual charges, and 32 charge categories. Reading and parsing that manually is impossible.
Loop’s Charge Sets are the charges on one invoice grouped by the shipment or tracking number they belong to. Each group includes the origin, destination, vendor, and reference information needed to make the coding decision. Reviewers can filter to the shipments that need attention, apply a cost code across multiple charges, and see anything still uncoded. Automated assignments can be overridden, and those overrides persist through reprocessing. Rules can also leave a line uncoded when the right answer is not available, so a disputed charge is held for review rather than force-coded.
The result is a workflow that matches how an analyst thinks about the work: shipment by shipment, not charge by charge.
Even if a code is present, it’s not uncommon for that code to be incomplete, invalid, or too broad. For organizations that need accurate GL coding on every shipment, Loop's policies can make checking codes a part of the payment decision.
Loop can require complete coding before approval or payment, and once a line is approved its coding locks. Manually entered codes can be checked against the company’s own cost code catalog at entry. Invalid codes are rejected with the reason shown inline, and a legitimate new code can be added without leaving the screen.
Automation can assign one code to each line item for each code type. For freight charges that genuinely need to be divided across accounts, a person sets the percentages. That is deliberate. Nothing on an invoice can tell Loop that a shared container was 60% one brand and 40% another. That answer comes from what was inside the shipment or from an agreement between teams. The system leaves that judgment with the people who have the context instead of making an unsupported split.
Where a traceable answer exists, Loop’s rules should find it. Where the available data does not provide one, the charge can remain uncoded for review.
Freight arrives in one shape and the business needs it in another: a carrier bills by invoice, while finance thinks in materials, stores, brands, and accounts. Once every charge carries a code derived from the company’s own reference data, with the decision visible and checked before payment, freight stops being one unexplained number and becomes a cost the business can act on.
