SAP Confirmation

As operations are completed on the shop floor, confirmations record the actual yield (good quantity), scrap, and the actual times (setup, machine, labour) for each operation. This updates the order’s progress, consumes activities for costing, and (at final confirmation/goods receipt) brings the finished product into stock.

It is also the point at which the plan stops being a plan. Everything before a confirmation is intention: an order exists, dates are calculated, components are reserved. The confirmation is the first statement about what actually happened, which is why it feeds stock, cost and every operational measure at once rather than being a status update.

• Operation confirmations: quantities, times, scrap.
• Automatic goods movements: backflush of components, GR of product.
• Actual costs: activities consumed at the work center.
• Progress/variance vs plan.

One term worth defining because it appears constantly and is easy to misread: the open quantity on an operation is what remains to confirm, and it is reduced by yield and by scrap together. So an operation with ten units planned, seven confirmed as yield and three as scrap is fully confirmed, and the order will not expect more even though only seven good units exist.

A confirmation looks like data entry and it is a financial posting, which is why accuracy matters more than the screen suggests.

Yield is the good quantity produced. It reduces what remains open on the operation and, on the final operation, is what the goods receipt is expected to match.

Scrap is quantity lost. It is recorded separately because scrap is a cost the business wants to see rather than a quantity that quietly disappears.

Activities are the times: setup, machine, labour, per the standard value key on the work centre. Each is multiplied by that work centre's activity rate, and the result is posted as an actual cost to the order and as a credit to the cost centre that provided the capacity. That second half is what people miss: confirming time moves cost out of a cost centre and onto a product.

Backflushed components are consumed automatically where configured, so a confirmation can also generate goods issues.

So a careless confirmation with the wrong hours does three things at once: it misstates the product cost, it misstates the cost centre's absorption, and it produces a variance that looks like a manufacturing problem.

Half an hour, and it connects the shop floor to the ledger.

1. Take a released production order and note its planned costs.
2. Confirm the first operation with CO11N, entering the actual times honestly.
3. Open the order's cost analysis. Actual costs have appeared for the activities you confirmed.
4. Look at the cost centre providing that work centre's capacity. It has been credited, because its time was consumed by the order.
5. Now confirm the next operation with times far higher than planned. The variance grows, and it is visible as a difference between plan and actual on the order.
6. Cancel a confirmation with CO13 and check that the postings reverse rather than being edited.

Step four is the one worth understanding, because it is how manufacturing cost accounting actually works: cost centres absorb their costs into products through confirmed activity. See work centres for where the rates live.

Confirmations are how planned production becomes actuals: they drive accurate inventory (components consumed, product received), manufacturing costs (actual activities), and shop-floor visibility. Missing or wrong confirmations cause wrong stock and costs, so timely, accurate confirmation is essential for reliable PP and CO data.

It is also the data that feeds every operational measure the plant is judged on: throughput, yield, scrap rate, machine utilisation and schedule adherence. All of them are computed from confirmations, so a plant that confirms in batches at the end of the week has reporting that describes last week rather than today.

• Where confirmation happens. At a terminal on the line, on a mobile device, or typed later by an office. The closer to the moment, the more accurate everything downstream is.
• Milestone or every operation. Confirming every operation gives full visibility and costs time on a long routing. Milestones confirm the preceding operations automatically, which is the usual compromise.
• Whether times are proposed. Defaulting the planned times means confirmations record the plan rather than reality, which makes variance analysis meaningless while looking tidy.
• Backflushing. Automatic component consumption saves effort and hides discrepancies.

The screen is one route and rarely the main one in a working plant.

Individual confirmation through CO11N is what training shows: one operation, one order, typed by a person.

Collective entry handles many at once, which suits an office confirming a shift's work from paper.

Time tickets and shop floor terminals put confirmation at the machine, which is where accuracy comes from, because the numbers are entered by somebody who just did the work.

Barcode and mobile scanning does the same with less typing.

Automatic confirmation from a machine interface or a manufacturing execution system removes the human entirely, and it is the direction most serious manufacturing has gone.

Milestone confirmation is a shortcut rather than a channel: confirming one operation automatically confirms the preceding ones, which suits long routings where intermediate detail is not worth capturing.

The design decision is between accuracy and effort, and it is worth being honest about. Confirmation at the machine gives the best data and needs hardware and training. Confirmation typed on Friday from memory gives you numbers that describe roughly what happened, and every measure built on them inherits that.

Confirmations are financial postings, so correcting one is a reversal rather than an edit, and the route matters.

CO13 cancels a confirmation. It reverses the activity postings, the backflushed component issues and the yield, leaving both the original and the cancellation in the record. Then a correct confirmation is entered.

What people do instead is confirm a negative quantity to net things off, which produces a total that looks right and a history that reads as two separate production events. Reporting on yield or scrap then counts both.

Where goods movements were backflushed, cancelling reverses them too, which occasionally fails if the stock has since moved. That is the case that needs care: the confirmation cancels and the component issue cannot reverse because the stock is gone, leaving the two out of step.

The habit that avoids most of this is confirming promptly and accurately rather than confirming something to close the order and correcting later, because the correction is always more work than the original entry.

• Missing/late confirmations, wrong stock and costs.
• Incorrect yield/scrap distorting actuals.
• Backflush errors mis-consuming components.

• Confirming the planned time by default. The variance is then always zero and nobody learns anything.
• Scrap recorded as yield. The cost stays in the product and the quality problem stays invisible.
• Correcting by confirming a negative rather than cancelling. See scheduling and production orders for what confirmations close.

• Backflushing switched on for components that are not consistently consumed. The stock record drifts and the discrepancy surfaces at a count months later.

Entering a confirmation is trivial, and configuring where and how it is captured so the cost and the measures are trustworthy is the part you do in the course.

The check that reveals whether confirmations are trustworthy: compare confirmed times against planned times across a month. If the variance is consistently zero, somebody is confirming the proposal, and every measure built on that data is describing the plan rather than the plant.