Skip to main content
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 the Payables board 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 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, does not change a vendor payables balance, 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) 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 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 — 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) 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. 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. 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 (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 — 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 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.