> ## Documentation Index > Fetch the complete documentation index at: https://docs.garmentflow.ai/llms.txt > Use this file to discover all available pages before exploring further. # Cost allocation > How GarmentFlow distributes an order's non-production costs (freight, inspection, customs, packaging, testing) across the styles on that order so each style's loaded cost and profit can be read on its own — the basis the platform uses, the report surfaces it produces, and the audience it is restricted to. A finished apparel order rarely carries only the cost of the goods. A single order also picks up **non-production costs** along the way — the freight that ships the goods, the inspection that signs them off, the customs and import charges that clear them at the border, the packaging that prepares them, and the testing that certifies them. Those costs are recorded once, against the order, as vendor invoices in the [non-production cost types](/concepts/finance-ledger#the-kinds-of-entries) the [Payables board](/modules/payables) carries. A team that runs more than one style on the same order has a follow-on question every time it reads a profit number: *how much of that order's freight was really this style's? how much of the inspection bill belonged to the other one?* The answer is **cost allocation** — the rule the platform uses to distribute an order's non-production costs across the styles on the order, so each style's loaded cost and profit can be read on its own. This page explains what cost allocation is, the basis the platform uses, and where the result surfaces. The [Finance reports](/modules/finance-reports#order-profit-and-customer-profit) page describes the on-screen reports that show the allocated figures; this page is the canonical place for the model. ## What cost allocation is Cost allocation is a **read-time overlay** on the order's already-recorded costs. It does not post a new movement to the [finance ledger](/concepts/finance-ledger), does not change a vendor [payables balance](/modules/payables), and does not edit the source vendor invoices. The order's recorded total in payables remains exactly the sum of the vendor invoices that produced it. What cost allocation adds is the per- style view: a number against each style on the order that says how much of the order's non-production cost pool was attributed to that style. The result is a **loaded cost** for each style — the style's own direct cost (the production cost recorded against it on its [cost sheet](/modules/cost-sheet)) plus the share of the order's non-production costs attributed to it by the allocation rule. The style's profit is then its revenue (the order's selling amount for that style) minus its loaded cost. The allocation always sums **exactly** to the order's non-production cost pool. The platform distributes the pool whole-cent by whole-cent so no money is created and no money is lost; the per-style figures add up to the source total down to the cent. ## What gets allocated Only the order's **non-production costs** participate. These are the costs recorded against the order in the [Payables board](/modules/payables) as one of: * Freight * Inspection * Customs * Packaging * Testing The order's direct production costs — the factory cost of each style as it sits on the style's [cost sheet](/modules/cost-sheet) — are **not** allocated. They already belong to a specific style. Cost allocation only touches the costs that were recorded against the order as a whole and that need to be split before a per-style profit can be read. A non-production cost recorded against a vendor without a specific order is **not** in the pool — there is no order to allocate it across. Those costs appear on the workspace's expense reports (see [Finance reports → Expense analysis](/modules/finance-reports#expense-analysis)) but do not feed an order's loaded cost. ## The basis used to allocate The platform supports three allocation bases. Every order uses one of them across all of its non-production cost pool — the basis is consistent for the order, so the same rule produces every per-style figure. * **By amount (default).** Each style's share of the pool is **proportional to the style's direct production cost** on this order. A style that carries a larger production cost on the order picks up a larger share of the freight, inspection, and other non-production costs. This is the default basis for every order, on the working principle that costs that scale with the size of the work usually scale with the value of the work. * **By ratio.** Each style on the order is assigned a weight, and the pool is distributed by those weights. This is the basis the team reaches for when a particular style is known to have driven more of the freight or inspection than its production cost would suggest — a heavier garment that drove most of the freight, for example, or a style that required a separate inspection pass that the others did not. * **By average.** The pool is split equally across the styles on the order, regardless of their production costs. This is the basis the team reaches for when no single style can fairly be said to have driven more of the non-production cost than the others. Whichever basis applies, the allocation is read fresh every time the profitability reports are opened — there is nothing saved on the ledger to fall out of step. A non-production cost added to the order tomorrow shows up in the per-style allocation the next time the report is read. ## Where the result surfaces You do not open a cost-allocation screen of its own. The allocated figures surface in the Finance module's **Reports (報表)** tab, on two reports: * **[Order Profit](/modules/finance-reports#order-profit-and-customer-profit).** One row per order, with the order's revenue, direct production cost, allocated non-production cost, loaded cost (direct + allocated), profit, and the margin percentage off revenue. The allocation runs per order, so the figures on this report are the order's own. * **[Customer Profit](/modules/finance-reports#order-profit-and-customer-profit).** One row per customer, aggregating every revenue-bearing order for that customer — the revenue, the loaded cost (rolled up from each order's allocated total), the profit, and the margin percentage. The customer- level number is the running roll-up of the order-level allocations, not a separate calculation. Both reports are limited to **revenue-bearing orders** — orders that are **Confirmed** or further along the [order lifecycle](/concepts/order-lifecycle) (Confirmed, Sample, PP-sample, Production, Shipping, Completed). Inquiry and Quotation stages are not yet real orders, and Cancelled orders are excluded on the same basis. ## Who can see it Cost allocation is an **internal-only** view. The Order Profit and Customer Profit reports — and every other surface that shows profit, margin, or loaded cost — are restricted to roles that have a business reason to see the workspace's profit figures: **Administrator**, **Supervisor**, **Finance**, and **Finance checker**. **Sales** and **Merchandiser** roles, who reach much of the rest of the workspace, do not see the profitability reports at all; the tab opens for them with the rest of the Reports surface, but the Order Profit and Customer Profit tabs are not available to those roles. The customer-facing [Statement of Account](/modules/statement-of-account) — the document that goes to the customer — is also **margin-free**: it carries the receivables and payments the customer needs to read, and never the workspace's profit or cost figures. Cost allocation sits behind the workspace's own reporting, not behind anything the customer sees. See [User management → Roles](/admin/user-management#roles) for the full role rules and what each role can reach in the Finance module. ## Why it is read-time, not posted A team reading a profit report needs to trust two things at once: that the order's recorded total in payables matches the vendor invoices that produced it (the side the workspace pays from), and that each style's loaded cost is a fair attribution of the same pool (the side the workspace reports profit from). Posting the allocated amounts as ledger entries would risk drifting the two apart — the moment a non-production cost was added or a vendor invoice was corrected, the saved per-style figures would need to be recomputed or they would be wrong. Reading the allocation off the source pool every time keeps the two views in step by construction: the per-style figures are always the current attribution of the current pool, and the source pool is always the sum of its vendor invoices. The trade-off is that the per-style figures are a *report view*, not a *posted balance*. They are read on the reports above and on the order's profitability roll-ups; they are not a separate balance the workspace keeps on the ledger. ## Related concepts * [The finance ledger](/concepts/finance-ledger) * [Order lifecycle](/concepts/order-lifecycle) * [Cost sheet](/modules/cost-sheet) * [Finance reports](/modules/finance-reports) * [Payables](/modules/payables)