LT12 — Confirm Transfer Order Single Entry

LT12 confirms an existing transfer order in classic Warehouse Management (LE-WM), the step that turns a planned bin-to-bin movement into an executed one. Confirming updates the quant table with the new bin stock position and, depending on movement type, triggers a goods movement in inventory management. The one structural fact that explains most confusion: a TO can already be confirmed automatically the moment it is created, controlled by a confirmation setting on the movement type and storage type combination. When that setting is active, the TO never reaches an open, confirmable state, and a consultant trying to use LT12 on it gets an 'already confirmed' message that looks like a data error but is actually expected behavior. LT12 only matters for TOs that were deliberately left open for manual, two-step confirmation.

LT12 is reached for in warehouses that do not use RF or barcode scanning for putaway and picking, or in any warehouse where a specific movement was left as two-step for exception handling. It is the tool for closing out a TO manually after a picker or forklift operator reports completion verbally or on paper, and for correcting a confirmation where the physical quantity moved differs from the planned quantity. It also comes up during testing and cutover simulation, where consultants confirm TOs by hand to validate stock movement logic before RF or interfaces go live. In a live RF warehouse, the equivalent action normally happens through the RF transaction itself; LT12 is then reserved for stuck or orphaned TOs that RF cannot pick up, and for support tickets where a TO needs to be closed outside the mobile flow.

Start in SE16 on LTAK filtered by the TO number to read the confirmation status field and confirm whether the TO is open, partially confirmed, or fully confirmed. Drill into LTAP for the same TO number to compare the planned quantity field against the confirmed quantity field, item by item, and to read the source and destination bin. Then check LQUA for the destination bin and material to confirm the quant reflects the expected stock after save. If a movement document was expected, check MSEG for a document with a matching reference to the TO to prove whether the inventory posting actually fired.

Classic Warehouse Management, including LT12, still runs on S/4HANA where a customer has not migrated to embedded or decentralized Extended Warehouse Management, and the transaction behaves the same as in ECC. There is no dedicated Fiori app for single TO confirmation in classic WM. Once a warehouse is converted to EWM, the transfer order concept is replaced by the warehouse task, confirmed through EWM's own confirmation transactions and RF framework rather than through LT12, so the transaction becomes irrelevant for that warehouse number, not just cosmetically different.

This is a functional WM problem first: the movement type confirmation control, difference indicator configuration, and storage bin capacity settings all sit in warehouse management configuration. Basis involvement is limited to authorization failures or posting locks at save time caused by period or material master status. A good handover includes the TO number, item, storage type, planned versus actual quantity, the exact error message text, and the confirmation control setting on the relevant movement type.

Read LT01 first to understand how a TO's confirmation control is set at creation, since that setting determines whether LT12 will ever have anything to confirm. LT21, LT22 and LT23 are the display transactions for finding open or already-confirmed TOs by storage type, material or group, and are the natural first stop before running LT12 on a ticket. LS26 shows current bin stock and is the fastest way to prove whether a confirmation actually posted. LX03 is useful when a confirmation appears to have posted a quantity that does not match physical count, pointing toward an inventory difference investigation rather than a WM configuration issue.