Vertical SaaS · Customization

Acumatica Manufacturing — BOM and Routing Basics

A clear introduction to Acumatica Manufacturing — bills of material, routings, work centers, and the data model that powers MRP, production orders, and cost rollups.

John Kihiu12 min read

Every discrete manufacturer running Acumatica lives or dies by two records: the Bill of Material and the Routing. The BOM says what goes into a finished item; the routing says what work happens, in what sequence, at what cost. Get the relationship between them wrong and MRP mis-plans, backflushing consumes the wrong component, and cost rollups quietly drift from reality. This is the basic model every AM implementation builds on.

BOM header, revisions, and status

A Bill of Material is created on the Bill of Material screen (AM208000) against an inventory item, warehouse, and revision. Only one revision per item/warehouse combination can be Active at a time — the rest sit as Hold, Pending Approval, or expired. Effective and expiration dates let engineering push a new revision live on a future date without touching production today, which is how you handle an engineering change order (ECO) without a scramble.

Revision control matters more than people expect. If you edit an Active BOM directly instead of creating a new revision, you lose the audit trail of what changed and when — and any production order already released against the old revision won't reflect the edit unless it's still in a stage that re-pulls the BOM.

BOM lines: material, quantity, and issue method

Each BOM line specifies a component item, the quantity required per unit of the parent, unit of measure, and a scrap percentage that inflates the planned consumption to account for expected waste. The issue method on the line — Manual or Backflush — determines how material actually leaves inventory: Manual means someone issues it explicitly against the production order, Backflush means the system consumes it automatically when the linked operation is reported complete.

The field that ties a BOM line to manufacturing execution is the Operation ID. Every material line references an operation sequence number from the routing, so the system knows which production step consumes that component. This is what makes backflushing possible — when operation 20 is reported done, only the material lines tied to operation 20 get consumed, not the whole BOM at once.

Routing operations and work centers

Routing operations are maintained alongside the BOM, most conveniently through Engineering Workbench (AM209500), which shows BOM lines and routing steps side by side for comparison across revisions. Each operation is assigned a work center and carries setup time, run time (usually per unit or per lot), queue time, and move time. Labor and machine rates attached to the work center feed straight into the costed rollup — a routing with the wrong work center on one step is enough to skew the standard cost of everything built from it.

Operation sequence numbers (10, 20, 30, and so on, leaving gaps for insertions) are the backbone that BOM lines hook into. Get the sequence wrong — say, a component numbered against operation 30 when it's actually consumed at operation 10 — and backflush timing and work-in-process valuation both go wrong even though the BOM itself "looks" correct on screen.

Multi-level BOMs hide the real cost driver

A subassembly BOM's cost only rolls up correctly if its own BOM has been costed first. Run the Cost Rollup process bottom-up through the structure — if a subassembly's standard cost is stale, every parent item that consumes it inherits the stale number silently. There's no warning on the parent BOM that a child cost is out of date.

Single-level vs. multi-level BOMs

A single-level BOM lists only the components consumed directly by the parent item. A multi-level (nested) BOM includes subassemblies that themselves have BOMs, several layers deep in some manufacturers. Acumatica's Cost Rollup process walks the full structure and aggregates material, labor, and overhead at each level into the standard cost of the item above it, which then feeds production cost estimates and, eventually, actual-vs-standard variance reporting on the production order.

Where-Used inquiry is the tool for the other direction: given a component, it shows every BOM that consumes it. Before retiring a part number or changing a supplier's spec, running Where-Used tells you the blast radius — which finished items, and by extension which open production orders and sales commitments, are affected.

BOM vs. routing: who owns what

ConcernBill of MaterialRouting
DefinesWhat materials and quantities are consumedWhat operations happen and in what order
ScreenBill of Material (AM208000)Engineering Workbench (AM209500)
Cost contributionMaterial costLabor and machine (overhead) cost
DrivesMRP material requirements, backflush consumptionCapacity planning, scheduling, labor reporting
Linked byOperation ID on each lineOperation sequence number

A quick BQL sketch of the kind of cost-rollup inquiry this relationship supports — joining BOM lines to their routing operations for a landed material-plus-labor view per operation:

C# · BQL
// Illustrative — join BOM lines to routing operations by BOM ID + Operation ID
PXSelectJoin,
        And>>>,
    Where>>>
    .Select(graph, bomID);
// Each row pairs a material line with the operation that consumes it,
// which is exactly what backflush and cost rollup rely on at runtime.

Wrapping up

BOM and routing look like two separate screens, but they're really one data model: material lines are meaningless without the operation sequence they consume against, and routing steps are meaningless without the cost and material they're driving. I've untangled this relationship on client sites from Nairobi to Johannesburg, Kigali, Lusaka, and Harare, usually while chasing a cost variance or a backflush that fired against the wrong operation. If you're working through a BOM or routing issue, reach out or browse more Acumatica manufacturing posts on the blog.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.