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.
Published 20 Sept 2026· 1,150 words
Diese Seite ist noch nicht auf Deutsch verfügbar.
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 — confirmation records, including yield, scrap, confirmed dates and final-confirmation indicators.
- AFVC/AFVV — order operation and quantity/date data.
- AFPO — production-order item and delivered quantity context.
- RESB — component reservations and withdrawal context.
- S/4HANA goods movements — MATDOC is the primary material-document persistence model; MKPF/MSEG names are compatibility-oriented.
- Accounting/actual-cost impact — use current FI/CO/Universal Journal views appropriate to the posting.
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 remains a production-order confirmation transaction in S/4HANA. Confirmation records remain centered on AFRU and order-operation data, while any automatic goods movements use the S/4HANA MM-IM model: MATDOC is the primary material-document persistence table and MKPF/MSEG references are ECC-era or compatibility-oriented. Fiori confirmation apps may provide an alternative user experience.
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.