Acumatica Margins by Product Report — Building It Right

Margin-by-product reports are where the difference between "the report ran fine" and "the report told finance the right thing" really shows up, because product margin is sensitive to exactly which cost you compare revenue against, and there are at least three defensible answers depending on who's asking.

Standard cost, actual cost, or landed cost — pick one on purpose

Sales wants margin against standard cost, because it's stable and lets them compare quoting decisions without variance noise from a supplier's bad week. Finance wants margin against actual issued cost, because that's what actually hit the P&L. If the product involves imported goods, landed cost (item cost plus freight, duty, and clearing charges allocated back to the item) can differ meaningfully from both. Building one report that silently uses whichever cost happens to be easiest to join produces a number that's defensible to nobody, because the person reading it assumes their definition was used. State the cost basis in the report title and offer it as an explicit toggle if more than one audience uses the same report.

CostField = IIf([@CostBasis] = 'STD', InventoryItem.StdCost,
             IIf([@CostBasis] = 'ACTUAL', SOShipLine.TranCost,
                 InventoryItem.StdCost + LandedCostAllocation.AllocatedAmt))
Margin = Revenue - (Qty * CostField)

Decide the grouping grain before building the schema

"Margin by product" means different things: by inventory item (thousands of rows, precise), by item class or product category (dozens of rows, useful for a management review), or by a custom product line grouping that doesn't map cleanly to Acumatica's item class hierarchy at all. Building the report at item grain and hoping the layout can roll it up to category with a group header is fine — but confirm the category assignment on InventoryItem.ItemClassID or whatever custom classification field the client actually uses is populated and maintained, because a margin-by-category report where half the items have no category assigned produces a large, wrong "Uncategorized" bucket that undermines trust in the whole report on day one.

Returns pull margin in a direction people don't expect

A returned item reverses revenue and reverses the matching cost — but if the return happens in a later period than the original sale, and your report groups by period, the return shows up as negative revenue with no matching cost in that period unless you also net the original cost reversal into the same period bucket. Left unhandled, this makes a period's margin percentage look artificially bad (revenue down, cost unchanged) purely because of return timing. Decide whether returns should net back into their original sale period or show in the return's own period as a deliberate variance line — either is defensible, but pick one and be consistent, and say which one the report does in a footnote.

Wrapping up

Pick and state a cost basis explicitly — standard, actual, or landed — because each answers a different question and none of them is more "correct" in the abstract. Confirm the grouping field is actually populated before building a category-level report around it, decide deliberately how returns net against period margin, and allocate header-level discounts and freight down to line level so per-product margin isn't quietly overstated.