CO11N — Production Order Confirmation Single Screen
CO11N is the standard transaction for entering time and quantity confirmations against a production or process order operation. It records yield, scrap, and activity quantities, triggers automatic goods movements for backflushed components, posts activity costs to the order, and can set the operation or order to final confirmed. It replaced CO11 as the default entry screen.
CO11N is the workhorse transaction for shop floor confirmation in discrete and repetitive manufacturing. This page covers what a save actually writes, the sequence a consultant should follow when a confirmation fails or posts wrong quantities, and the diagnostic categories that account for most CO11N incidents: backflush failures, reversal confusion, final confirmation errors, and costing gaps.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,223 words
Purpose
CO11N confirms that an operation on a production or process order has been executed, in full or in part, and records how much was produced, how much was scrapped, and how long the work center or activity was used. The single structural fact that drives most confusion is that one confirmation posting can trigger three separate downstream effects at once: a goods receipt of the yield if the routing calls for automatic GR, a goods issue of components if backflush is set on the material or work center, and a cost posting of the activity types entered or defaulted from the work center. When any one of those three fails, the confirmation itself can still save successfully, which is why a clean CO11N screen does not mean the business transaction actually completed.
When it is used
CO11N sits at the execution end of the order lifecycle, after release (CO02 or COR2) and before technical completion and settlement. Shop floor staff or a supervisor use it to report progress on an operation as work happens, either confirming the full order quantity at the last operation or confirming intermediate operations along the routing. A consultant reaches for CO11N directly when troubleshooting a single confirmation that misbehaved, or when a user reports a goods movement that did not happen. For volume confirmation across many orders, CO15 or a background job using the confirmation collective processing variant is used instead; for repetitive manufacturing, backflush confirmation happens through a different transaction entirely. The Fiori app for confirmation covers the same use case for users who no longer have GUI access.
How to use it in practice
- Enter the order number, or the operation and work center if confirming by operation, on the initial screen.
- Select the confirmation type: partial, final, or clear open reservations, since this flag controls whether the operation is considered done.
- Review or overwrite the default yield quantity, scrap quantity, and activity quantities that CO11N proposes from the order.
- Check the goods movements tab for backflush components and correct batch, storage location, or quantity before saving if the system flags a shortage.
- Save. If the goods movement cannot post, the confirmation itself still saves and the failed movement lands in the confirmation error log for later correction.
- Reverse a wrong confirmation with the cancellation function inside CO11N or with CO13, never by entering a negative quantity.
Key data objects
- AFRU - the confirmation header and detail record, one row per confirmation posting, holding confirmed quantity, scrap, work center, and the final confirmation indicator.
- AFVC and AFVV - the order operation and its quantity and date fields, updated with confirmed-to-date totals after each posting.
- AFPO - the order item, updated with delivered quantity when the confirmation triggers an automatic goods receipt.
- COEP - the CO line item for the activity cost posted from the confirmed activity types and rates.
- MSEG and MKPF - the material document created for backflushed component consumption or automatic goods receipt.
- RESB - the reservation for components, reduced or cleared as backflush consumption posts against it.
How to prove it in the data
Pull AFRU filtered on the order number (AUFNR) and operation to see every confirmation posted, including the confirmed quantity, scrap quantity (AFRU-XMNGA and similar scrap fields), the final confirmation flag (AFRU-ISM), and the cancellation indicator (AFRU-STOKZ) to spot a confirmation that was reversed. Cross-check the confirmation number against the material document number stored in the confirmation to confirm whether a goods movement actually posted, then look up that document in MKPF and MSEG. If no material document number is present but a backflush was expected, the confirmation posted with an error that needs correction from the goods movement error worklist.
ECC vs S/4HANA
CO11N behaves the same functionally on S/4HANA as on ECC; the underlying document structure for confirmations was not restructured the way order and material master tables were. The Fiori app for confirming production orders covers the same scenario for users working outside the GUI, and both write to the same AFRU-based data model. No mandatory migration of open confirmations is required beyond the standard order data conversion carried out during the S/4HANA technical upgrade.
Common pitfalls and how to diagnose them
- Backflush failures: the confirmation saves but no material document appears against the expected component. Check the component's storage location and batch determination settings first, since a missing storage location on the BOM item or a batch not found is the most common cause; the failed movement sits in the confirmation error correction worklist and must be fixed there, not by re-entering the confirmation.
- Reversal confusion: entering a negative quantity to correct an over-confirmation instead of using the cancellation function leaves AFRU with two inconsistent rows and can double-count activity cost. Always cancel through CO13 or the CO11N cancel function so the original confirmation number is properly referenced and reversed.
- Final confirmation set too early: a user ticks final confirmation on an intermediate operation, which closes the operation to further confirmation even though quantity remains outstanding. The fix is to clear the final confirmation indicator on that AFRU record and re-open the operation before further postings are attempted.
- Order stuck at confirmed but not settling correctly: variance between confirmed activity quantities and the standard cost estimate's planned activity consumption, usually because the work center's formula or the activity type rate was changed after the order was created. Compare the order's planned versus confirmed activity in COOIS before assuming settlement is broken.
- Overdelivery or underdelivery tolerance errors: the system rejects a confirmation quantity outside the tolerance maintained on the material master or routing; check the tolerance fields before assuming the confirmation transaction itself is faulty.
- Costing gaps: activity cost does not post because the cost center or activity type behind the work center has no valid rate for the posting period; this shows as a zero-value COEP line rather than a hard error, so it is easy to miss.
Whose problem this is
CO11N is a PP functional consultant's transaction end to end: confirmation logic, backflush setup, and activity determination are all Customizing and master data decisions. Basis involvement is limited to background job scheduling for collective confirmation runs. A good handover includes the order number, operation, the AFRU record in question, whether a material document was expected, and the exact error message text from the goods movement log if backflush failed.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/co11nERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.