Backflush and Automatic Goods Receipt: Confirmation Posts the 261 and the 101
The same discrete production order, but nobody posts goods movements by hand: the confirmation (CO11N) backflushes the components (261) and receives the finished product (101) automatically. Failed movements land in COGI.
Educational content. SAP behaviour varies by configuration and release. Spotted something off? Report it.
Digital twin
01A released order with backflush components
Order 1000002 is released. Its component RM-1000 carries the backflush indicator.
Component overview
Production Order 1000002
- Component
- RM-1000
- Quantity
- 100 EA
- Backflush
- Yes
Business scenario
Production order 1000002 builds 100 EA of FG-2000. RM-1000 is a cheap, high-volume component staged line-side, so it is flagged for backflush, and the final operation's control key posts the goods receipt automatically.
All companies, numbers and documents are fictional demo data.
Step-by-step flow
- 01
A released order with backflush components open in twin
Order 1000002 is released. Its component RM-1000 carries the backflush indicator.
For cheap, high-volume parts, posting each withdrawal by hand costs more than it is worth. Backflush books consumption at the moment the work is reported.
- 02
Components move to the line — no posting open in twin
100 EA of RM-1000 are brought to the line. SAP stock is unchanged: still 300 EA.
This is the defining trait of backflush: stock in the system lags physical consumption until confirmation.
- 03
Building is finished open in twin
All 100 assemblies are built. Before confirming, does someone need to post the 261 in MIGO?
With backflush set, the confirmation will consume the components whatever has been posted before.
- 04
Components consumed twice open in twin
The manual 261 and the backflush both post: 200 EA consumed for 100 built. Stock and order costs are both wrong.
Mixing the two methods for the same component is a common cause of stock shortfalls and inflated order costs.
- 05
Confirm — backflush and goods receipt post open in twin
CO11N: 100 EA yield, 48 h. RM-1000 300 → 200 (261) and FG-2000 40 → 140 (101) in one save.
It brings system stock back in line with the shop floor in a single step, with no MIGO postings at all.
- 06
Check COGI for failed movements open in twin
COGI is empty: every backflushed and automatic movement posted. Nothing waits for correction.
Backflush errors do not stop the confirmation, so they are easy to miss. Daily COGI monitoring is part of running backflush safely.
- 07
Settle a favourable variance open in twin
Debits ₹1,19,200, credit ₹1,20,000: the order over-recovered by ₹800. Settlement clears it.
Backflush changes how consumption is triggered, not how the order is costed or closed.
- 08
Backflush cycle complete open in twin
One confirmation replaced two MIGO postings. COGI was clean and the order is settled.
Repetitive manufacturing takes the same idea further: no order at all, and a single backflush posting for everything.
SAP documents
Stock impact
| Step | Plant / SLoc | Stock type | MvT | Change |
|---|---|---|---|---|
| Confirm — backflush and goods receipt post | 1000 / 0002 | Unrestricted use | 261 | −100 EA |
| Confirm — backflush and goods receipt post | 1000 / 0001 | Unrestricted use | 101 | +100 EA |
Accounting impact
Backflushed components consumed by the order
TypicalConfirm — backflush and goods receipt post
- Dr Consumption — order 1000002 (GBB/VBR)₹1,00,000
- Cr Inventory — raw materials (BSX)₹1,00,000
Exactly the posting a manual 261 would make: consumption with the order as cost object, inventory credited. Only the trigger is different.
Automatic goods receipt of the finished product
TypicalConfirm — backflush and goods receipt post
- Dr Inventory — finished goods (BSX)₹1,20,000
- Cr Factory output — order 1000002 (GBB/AUF)₹1,20,000
The automatic receipt values the finished goods at standard price and credits the order through factory output, as a manual 101 would.
Activity allocation for confirmed machine hours
ConceptualConfirm — backflush and goods receipt post
- Dr Production order 1000002 — machine hours₹19,200
- Cr Cost center CC-4300 — activity allocation₹19,200
A controlling allocation from the work center's cost center to the order, valued at the activity rate.
Settlement of a favourable production variance
Configuration dependentSettle a favourable variance
- Dr Production order 1000002 — settlement₹800
- Cr Price difference — production variance (PRD)₹800
The line ran faster than standard (48 h vs 50 h), so the order holds a credit balance. Settlement to the material posts it to price difference as a favourable variance. Accounts depend on configuration.
Typical conceptual flow. Actual G/L accounts and posting behaviour depend on material valuation, automatic account determination and system configuration.
Movement type
Removes manual goods-movement postings from production: consumption and receipt are posted automatically when work is confirmed, keeping system stock close to the shop floor with less effort.
Transactions & Fiori apps
- CO11N — Confirmation (triggers backflush and automatic GR)
- COGI — Postprocess Defective Goods Movements
- CO02 — Change Production Order (component backflush indicator)
- KO88 — Order Settlement
- Confirm Production Operation
- Manage Production OrdersAvailability depends on release and scope
Differences by SAP version
Backflush and automatic goods receipt work as described; the material master MRP 2 view carries the backflush indicator.
Same functionality; postings land in MATDOC and ACDOCA. Fiori monitoring apps help track failed movements.
Configured through self-service configuration; the confirmation app triggers the same backflush and automatic receipt.
Configuration
Backflush indicator source
Configuration dependentThe material master can force backflush always, never or let the work center decide; the routing's component allocation can override.
Automatic goods receipt
Configuration dependentSet on the control key of the operation (and allowed by the order type) so the final confirmation posts the 101.
Error handling in confirmation parameters (OPK4)
Configuration dependentDecides whether failed goods movements go to COGI or block the confirmation.
Prerequisites
- Backflush indicator on the material master (MRP 2 view), the work center or the routing component allocation
- Components assigned to the operation whose confirmation should consume them
- Control key on the last operation allowing automatic goods receipt, if used
- Production storage location with enough stock to cover the backflushed quantity
Master data
- Material master (MRP 2 view)
- Backflush indicator and production storage location.
- Work center
- Backflush setting when the material leaves it to the work center.
- Routing component allocation
- Which operation's confirmation consumes each component.
Organizational structure
- Plant 1000
- Storage location 0002 (production supply)
- Work center ASSY-01
Tables
| Table | Description |
|---|---|
| AFRU | Confirmations |
| AFFW | Failed goods movements awaiting COGI |
| RESB | Reservations with the backflush indicator |
| MATDOC | Movements posted by the confirmation |
Integration
- MMStock is reduced and increased by the confirmation, not by MIGO.
- COOrder costs are identical to manual posting; only timing differs.
- FISame consumption and factory-output postings as manual 261 and 101.
Common errors
“Entries pile up in COGI”
Likely causes: Insufficient stock in the production storage location; Material or batch locked; Batch not determined; Posting period closed
Where to look: COGI error log · Stock overview for the production storage location · Batch determination settings
“Components consumed twice”
Likely causes: Manual 261 posted for a backflush component; Confirmation reversed and re-entered without checking movements
Where to look: Order goods movement list · Material documents for the order
“Finished goods not received after final confirmation”
Likely causes: Control key does not allow automatic goods receipt; Order type not set up for it; The receipt failed and is sitting in COGI
Where to look: Operation control key · COGI · Order type settings
Troubleshooting
Something went wrong? Work through these checks in order. They are diagnostic questions, not configuration instructions — confirm changes with your system owner.
CHECK 1
Backflush did not happen
- Is the backflush indicator set on the order component?
- Is the component assigned to the confirmed operation?
- Is the movement in COGI?
CHECK 2
COGI entries
- Is there enough stock in the production storage location?
- Is a batch required?
- Is the period open?
- Is the material locked?
Interview questions
What is backflushing and when would you recommend it?
Backflushing posts component consumption (261) automatically when the operation that uses them is confirmed, instead of a separate goods issue. It suits cheap, high-volume parts staged line-side, where manual withdrawals add effort but little control. It is less suitable for expensive or batch-critical components, where you want the issue checked before consumption.
Where can the backflush indicator be set, and which wins?
On the material master (MRP 2 view), the work center and the routing's component allocation. The material master can say always backflush, never, or let the work center decide; the routing component can also set it. The value on the order component is what is actually used at confirmation.
What is COGI and why does it matter?
COGI lists goods movements that a confirmation could not post — for example backflushed components with insufficient stock. The confirmation still saves, so the error is silent unless COGI is monitored. Until the entries are corrected and reposted, stock and order costs are incomplete.
Does backflushing change the accounting?
No. The postings are the same as a manual 261 and 101 — consumption against the order and factory output on receipt. Only the trigger and timing change.
Quiz
References
- SAP SE — SAP Help Portal: Backflushing in Production Orders (source)
- SAP SE — SAP Help Portal: Postprocessing of Goods Movements (COGI) (source)
- SAP SE — SAP Help Portal: Order Confirmation (source)
Explanations are original. They summarize standard behaviour; always validate against your system's release and configuration.
Version history
| Version | Change |
|---|---|
| 1.0.0 | Initial version. |