Work in process inventory by work order and operation

At shift handoff, you count twelve housings at finishing, but the work order report shows twenty. Work in process inventory is production that has started and still sits inside the manufacturing boundary. To explain the eight-unit gap, reconstruct what entered, moved, left, or was scrapped before the count (using the same cutoff and unit of measure for every record).

Start with one work order and follow it through its operations. A transfer can lower the balance at machining and raise it at finishing without changing total WIP. A final completion can remove units from WIP before the ERP receives the posting. Keep those events separate so the handoff tells the next shift what it can work on.

Decide when a unit enters and leaves WIP

For a discrete assembly line, choose observable boundaries. A blank enters this example’s WIP when machining starts, and a housing leaves when finishing is complete and the unit is accepted into finished goods. Blanks issued to the line but still waiting to start are tracked outside this operational count. Use the plant’s rule if it counts staged materials inside the boundary, and label that choice where the report is used.

Oracle documents work-order operation transactions that distinguish completion, rejection, and scrap. Its NetSuite documentation also separates work order issue, completion, and close when Manufacturing Work In Process is enabled. Read the status and transaction type together. A work order can stay open after some finished units have been stocked, so its open status alone cannot tell you how many units are still on the floor.

Use one balance per plant, work order, operation, and unit. Add lot or serial identity where the route requires it. A lot can split across stations, so store the quantity in each location instead of assigning the entire lot to the last scan. Keep a separate hold status for rejected parts that still await disposition. They remain in the operational WIP boundary in this example, but the next shift cannot schedule them as available pieces.

Rebuild the operation balances at handoff

Start with the opening count and add starts or transfers in. Subtract transfers out, accepted finished completions, and confirmed scrap within the window. Reverse a mistake with a linked event so the count can be reconstructed as it was known at handoff. Below, one work order moves through machining and finishing. All movements use individual housings as the unit, and the floor count and movements are hypothetical.

The physical count confirms twenty-two at machining and twelve at finishing. The ERP report shows twenty at finishing because it contains only fifteen of the twenty-three accepted units by the time you export it. A timestamped floor record shows the other eight accepted at 13:55, while the matching ERP completion posts at 14:07. The eight account for the gap only after the part, quantity, and work order match across both records.

Keep two views if the handoff and the ledger close serve different jobs. The 14:00 floor view can show twelve at finishing, with an eight-unit pending posting attached. The ERP view as exported at 14:00 can show twenty with its report timestamp. A later extract can confirm the posting and close the timing exception. Save the earlier extract if someone has to explain what the planner saw.

Give each unmatched movement an owner

Have the production lead check the floor event against the traveler or scan first. Compare source event IDs before summing rows. A missing transfer leg can look like extra stock at one operation even when the work order total seems plausible. A scrap ticket and its ERP transaction may describe the same three pieces, so keep the link and count the loss once.

Ask inventory control to check location and unit mismatches when the movement evidence agrees but the count does not. A tote quantity entered as individual pieces can make both adjacent operations look wrong. Keep the original value and the conversion applied, and mark the balance unresolved when a pack size or lot mapping is missing. Use Inventory reconciliation when you need to align the physical count scope with the ERP extract.

Route valuation questions to the cost owner after the quantities agree. The WIP quantity by operation does not establish what materials, labor, or overhead belong in the balance. For the separate cost flow from production through completed goods, see Total manufacturing cost formula.

Where Permute fits in the WIP handoff

Permute is the context layer we sell between business records and the AI tools people use. We can connect NetSuite and a supported spreadsheet containing shop-floor movements, then match the records by work order, operation, and lot when those identifiers are available.

We use the plant’s stated boundary and cutoff rules to produce a repeatable balance. Posting time and event time remain separate fields, so a later ERP posting can be tied back to the earlier shop-floor movement.

A production controller can ask which finishing balances changed after the last extract and get the affected work orders, movement references, and source timestamps they’re permitted to see.

Keep count corrections and valuation with their owners

We read connected records and report their differences. We do not write back into the system of record or decide whether a work-order correction should post. The plant verifies the count, and its accounting owner sets valuation and posting policy.

Close the handoff at the operation

A usable work in process inventory balance has an operation, a cutoff, and a record for every movement that changes it. The transfer moves housings across the floor, and the accepted completion moves them out of WIP. In the finishing example, the pending ERP transaction explains the gap once the eight units are matched to the floor record. Any gap that lacks that match stays open for the next shift to investigate.

Questions about shop-floor WIP balances