# SAP CO11N Confirmation Errors and How to Fix Them > Source: https://netray.co/erp-help/sap-co11n-confirmation-error-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer CO11N (time ticket confirmation for production/process orders) throws several distinct errors: deviation from the standard value is too large, goods movement not possible for a component, or the order/operation status does not allow confirmation. Each has a specific cause in order status, routing tolerance settings, or component availability, not a single generic fix. ## Kind error ## System sap ## Erp SAP ERP (ECC 6.0 / S/4HANA) ## Module Production Planning / Shop Floor Confirmation ## Query SAP CO11N confirmation error deviation too large ## Alternate Queries - SAP CO11N no goods movements possible for order - how to fix CO11N confirmation errors - SAP order confirmation not possible in this operation ## Applies To SAP ECC 6.0 and S/4HANA, PP (Production Planning) shop floor control ## Steps ### Diagnose and resolve CO11N errors **Items:** Read the exact message text and number in the status bar - CO11N surfaces different underlying issues under similar-sounding wording, so the message number (not just the text) determines the fix. For 'deviation of confirmed X from target Y is too large' style messages, check the work center's or routing operation's tolerance limits maintained in the routing (transaction CA02) or in the work center's standard value control. For goods movement failures during backflush, check component availability with CO09/MMBE for the components tied to that operation - a missing component blocks the automatic goods issue that CO11N tries to post alongside the confirmation. For 'confirmation not possible, order/operation has status X', check the order status in CO02 or CO03 - a technically completed (TECO), locked, or not-yet-released order or operation will reject confirmations until its status changes. If the error references a closed posting period, resolve it the same way as any FI period error - via OB52 for the FI side and MMRV for the MM side, since backflushed components post through both. For a genuine over-tolerance quantity or time deviation that is expected (rework, scrap, extra setup), confirm with the actual values and let the system generate the variance rather than forcing an artificial number to avoid the warning. Where confirmations are entered late in batches, check whether background job CO11N-based mass confirmation transactions (CO15, COR6N for process orders) are more appropriate than repeated single-order entry. ## Sections ### Deviation too large: where the tolerance lives **Body:** This message compares what you are confirming (time or quantity) against the standard value calculated from the routing operation, using a tolerance percentage. That tolerance is not a global system setting - it is maintained per work center (standard value key) or per operation in the routing, and different operations can have very different acceptable ranges. When the deviation is legitimate (a machine ran long, extra rework was needed), the correct action is usually to confirm the real value and accept the resulting variance report, not to force a number inside tolerance - the variance is exactly the information Controlling needs for standard cost variance analysis. ### Goods movement failures during confirmation **Body:** CO11N can attempt an automatic goods issue for backflushed components and an automatic goods receipt for the order's output in the same transaction. If a backflushed component is short, the confirmation itself can fail or generate a goods movement error alongside a partially posted confirmation, depending on configuration. This is functionally the same root cause as an M7 021 deficit error triggered from a different transaction - check component stock at the exact storage location the routing/BOM specifies before assuming the confirmation logic itself is broken. **Code:** - CO02 -> order -> Operations tab -> check status (REL, TECO, CNF) - CO09 -> component material + plant -> ATP for backflush components - CA02 -> routing operation -> Standard Value / tolerance settings ### Order and operation status control **Body:** Every production/process order carries system statuses (CRTD, REL, PCNF, CNF, TECO, CLSD) and optionally user statuses layered on top. Confirmation is only allowed once the order and the specific operation are released (REL), and is blocked once an order is technically completed (TECO) or closed (CLSD). A common real-world trigger is someone technically completing an order too early (before a final rework or scrap confirmation was entered), which then blocks the very confirmation that was still pending - the fix there is reversing TECO status (if authorized) rather than treating it as a data error. ### Batch and mass confirmation alternatives **Body:** CO11N is built for single time-ticket entry. For high-volume shop floors, CO15 (order confirmation, header level) or a mass processing variant is often a better fit and surfaces the same class of errors in a worklist rather than one order at a time. Process industry orders use COR6N instead of CO11N for the equivalent confirmation function; the underlying status, tolerance and component availability logic is the same, so the troubleshooting steps above apply equally. ## Pitfalls Forcing a confirmation value inside tolerance to avoid the deviation warning hides genuine variance data that standard costing and Controlling depend on for accurate variance analysis. Reversing a TECO status to allow a late confirmation can have downstream effects on settlement and period-end processing - coordinate with Controlling before reversing status on a closed order. A component shortage blocking automatic backflush goods issue is the same underlying stock problem as an M7 021 error elsewhere - fixing the confirmation without fixing the stock just moves the failure point. Confirmation-driven goods movements post to both FI and MM periods; if either OB52 or MMRV is closed for the relevant period, the confirmation can fail even when order status and tolerances are fine. Different work centers and routings can have very different tolerance percentages - do not assume one operation's tolerance setting applies system-wide when diagnosing a deviation error. ## Ai Angle ERPray grounded on your SAP PP data can classify a CO11N failure by message number and check order status, component ATP, and period status together in one query, so a shop floor supervisor gets 'this order is TECO, reverse status to confirm' or 'component 12345 is short at plant 1000' instead of chasing the cause across CO02, CO09, and OB52 separately. ## Faq ### Where do I change the tolerance for 'deviation too large' errors? **Answer:** In the routing operation (transaction CA02) or the work center's standard value settings, depending on how the tolerance was configured. It is set per operation or work center, not globally, so check the specific one referenced in the error. ### Why does CO11N fail with a stock error when I am only confirming time? **Answer:** CO11N can trigger automatic backflush goods issue for components and automatic goods receipt for output in the same step as the time confirmation. A component shortage or closed period can cause the associated goods movement to fail alongside the confirmation. ### Can I confirm an order that is technically completed (TECO)? **Answer:** No, not by default - TECO status blocks further confirmations. An authorized user needs to reverse the TECO status on the order before the pending confirmation can be entered, and this should be coordinated with Controlling if the order has already settled. ## Search terms SAP CO11N error, deviation too large SAP confirmation, SAP CO11N goods movement not possible, SAP order status TECO confirmation blocked, SAP CA02 tolerance standard value, SAP production order confirmation error, COR6N process order confirmation, SAP CO15 mass confirmation --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json