SAP Error: Movement Type 161 Is Not Allowed

✅ Fix: Movement Type 161 Is Not Allowed

🔧 Solution: Activate Movement Type 161 in OMJJ

1

Go to transaction OMJJ and select Movement Type.

2

Select movement type 161 - GR Returns from the list.

3

On the next screen, select Allowed Transactions and create a New Entry.

4

Enter the new entries: 161 - MIGO and 161 - MB1C, then save.

Save.

🔍 What Movement Type 161 Actually Does

Movement type 161 posts a Return to Vendor with reference to a purchase order - commonly called "GR Returns" since it's the logical reversal of the original goods receipt (movement type 101) against that same PO. Rather than being a standalone stock adjustment, 161 is tied directly to the original purchasing document, meaning the return quantity, price, and vendor are all inherited from the PO rather than entered fresh, and the posting typically flows through to generate a debit memo relevant document reducing what's owed to (or increasing what's owed by) the vendor for the returned quantity.

This PO-reference design is exactly why 161 needs to be explicitly allowed for the transactions used to post it - MIGO (the standard goods movement transaction, used when referencing a specific PO directly) and MB1C (a more general goods movement entry transaction, sometimes used for returns processed outside the standard PO-referenced MIGO flow) - since SAP treats "which movement types can be posted through which transactions" as a deliberate, configurable control rather than something universally open by default.

📋 Movement Type 161 vs. Related Return Movement Types

Confusing 161 and 122 is a common early-career mistake - if a return needs to reference and reduce against a specific purchase order (the far more common scenario in most procurement processes), 161 is the correct movement type; 122 is reserved for the less common case where no PO exists to reference at all. Using the wrong one doesn't just risk a similar "movement type not allowed" error - it can also mean the return doesn't correctly reduce the right purchasing document's received quantity, causing reconciliation issues later.

🔒 Why SAP Restricts Movement Types to Specific Transactions

The "Allowed Transactions" configuration this guide's fix walks through isn't a technical quirk - it's a deliberate governance mechanism. SAP lets an organization decide precisely which movement types end users can post through which specific transactions, rather than making every movement type universally available everywhere by default. This matters because different transactions carry different levels of built-in validation and different user populations: MIGO is a controlled, PO-referenced entry screen typically used by warehouse or receiving staff following a specific business process, while MB1C is a more general-purpose entry transaction that, depending on configuration, might be accessible to a broader group of users for various stock adjustments.

Restricting movement type 161 (or any movement type) to only the specific transactions genuinely needed for its real business use - rather than blanket-allowing it everywhere the first time this error appears - preserves the intent of this control. A movement type accidentally left available through an overly broad set of transactions can end up being used in ways the original process design never intended, which is why the prevention checklist later in this guide recommends deliberate, scoped configuration rather than reflexively allowing everything to make an error disappear quickly.

🔒 Who Should Have Access to Change OMJJ Settings

Because a movement type's Allowed Transactions list controls a genuine business process control - not just a technical toggle - most organizations restrict OMJJ access to a small group of MM configuration consultants, separate from general warehouse or purchasing transaction access. A movement type that's too broadly enabled undermines the deliberate scoping this control is meant to provide, while a movement type that's too narrowly enabled (as in this guide's core error) blocks legitimate business activity.

Some organizations require a documented business justification before adding a new Allowed Transactions entry - naming the specific process (in this case, return-to-vendor via MIGO) the change supports - so that a future reviewer understands why 161 is enabled for MIGO and MB1C specifically, rather than everywhere. This kind of lightweight documentation discipline pays off particularly during audits or when troubleshooting an unrelated movement type issue years later, when the original reasoning behind a configuration choice might otherwise be lost.

🧪 Testing Checklist for New Plant or Company Code Movement Type Setup

Given how often this error traces back to an incomplete configuration copy during new plant setup - exactly as in the real-world scenario in this guide - a deliberate test pass covering less-common movement types avoids discovering the gap only once a genuine business need arises in production.

• Test a full return-to-vendor cycle (161 via MIGO, referencing a real test PO) for every new plant, not just receipts (101) and issues (201/261).
• Confirm the resulting financial posting generates correctly, reducing the amount owed to the vendor as expected, not just that the MM-side posting succeeds.
• Test movement type 122 (return without PO reference) separately if your organization's process genuinely uses both scenarios, since they're configured independently.
• Test movement type 162 (reversal of 161) to confirm a mistaken return can actually be corrected, not just that the original return works.
• Compare the new plant's OMJJ Allowed Transactions configuration against a reference plant's directly, rather than relying purely on functional testing to catch every gap.

📦 Returning Goods from Quality Inspection or Blocked Stock

Movement type 161 as covered throughout this guide assumes the returned stock is coming from unrestricted-use status, which is the most common scenario. In practice, a meaningful share of real return-to-vendor postings actually originate from stock sitting in quality inspection or blocked status - for example, a batch that failed incoming quality inspection and needs to go straight back to the vendor without ever being released to unrestricted-use stock at all.

SAP handles this with movement type variants tied to the originating stock status - a return from quality inspection stock typically uses a distinct movement type (such as 351 in some configurations) rather than 161 directly, and similarly for blocked stock. If your organization's return process regularly involves quality-rejected or blocked stock rather than unrestricted-use stock, it's worth confirming the correct movement type variant for that specific scenario is also properly configured in OMJJ's Allowed Transactions - fixing 161 alone, as this guide's core solution covers, resolves returns from unrestricted-use stock, but a parallel gap can still exist for quality or blocked stock returns if they use a different movement type entirely.

This is worth checking specifically if your organization's return process is quality-driven - for example, in industries with strict incoming inspection requirements - since the receiving team's typical workflow (reject at inspection, return immediately) may never touch unrestricted-use stock or movement type 161 at all, meaning this guide's core fix alone might not fully resolve every return scenario your business actually needs.

❗ Common Mistakes When Fixing This Error

• Confusing movement type 161 with 122, using the wrong one for a PO-referenced return and encountering a similar but distinct configuration or process issue.
• Allowing 161 broadly across many transactions "just to be safe" rather than scoping the fix to the specific transactions (MIGO, and MB1C if genuinely needed) actually used for returns in your organization's process.
• Assuming a new plant's movement type configuration is complete simply because receipts and issues work, without specifically testing less-common but still important processes like returns.
• Not testing the actual return posting after the OMJJ fix, only confirming the configuration screen shows the new entry.
• Overlooking that 161 needs the original purchase order to still be referenceable - if the PO itself has issues (fully invoiced, blocked, or closed), a separate error can appear even after 161 is correctly allowed.

✅ Prevention Checklist for New Plant or Company Code Setup

• Include a genuine return-to-vendor test (movement type 161 via MIGO, referencing a real test PO) in every new plant's go-live testing checklist, not just receipt and issue tests.
• When copying movement type configuration from a reference plant, explicitly review the Allowed Transactions list for every movement type your organization actually uses, rather than assuming a copy captures everything correctly.
• Scope OMJJ changes to the specific transactions genuinely needed for each movement type's real business use, avoiding overly broad "allow everywhere" fixes that undermine the control's original purpose.
• Document which movement types are expected to be available through which transactions as part of your organization's standard MM configuration documentation, making future reviews and new plant setups faster.
• Periodically test less-common but still important processes (returns, transfers, scrapping) across all active plants, not just the frequently-exercised receipt and issue flows, to catch configuration gaps before they block a real business transaction.

📑 Similar-Looking SAP Movement Type Errors and How They Differ

These can look similar since they all block a goods movement, but each traces back to a distinct configuration layer - movement type/transaction restriction (OMJJ), material type-level posting restriction (OMS2), or genuine stock availability. Confirming exactly which layer is in play before troubleshooting saves considerable time.

📊 Auditing Movement Type Configuration Across Your Landscape

Beyond fixing a single failed posting reactively, periodically reviewing which movement types are allowed for which transactions - particularly after a new plant go-live, a system consolidation, or any project involving configuration copying - helps catch both types of gap discussed in this guide: movement types missing from transactions that genuinely need them, and movement types too broadly allowed in ways that undermine intended process controls.

• Review table T158B (or the equivalent Allowed Transactions configuration table) via SE16N, comparing movement type/transaction combinations across plants or company codes to spot inconsistencies.
• Cross-reference against actual business processes in use at each plant, confirming every movement type genuinely needed (receipts, issues, transfers, returns) has appropriate transaction coverage.
• Flag any movement type allowed through an unusually broad set of transactions, as in the second scenario above, for a deliberate review of whether that scope was intentional or an artifact of a rushed earlier fix.
• Document the intended scope for each movement type's Allowed Transactions configuration, making future audits and new plant setups faster and less error-prone.

This kind of periodic movement type configuration audit is particularly valuable after any project involving configuration copying between plants or company codes, since - as this guide's real-world scenario illustrates - a copy process can look complete on the surface while quietly missing entries for less-frequently-used but still important movement types.

📱 This Error in SAP S/4HANA

Movement type logic and OMJJ configuration, including the Allowed Transactions control this guide's fix relies on, are unchanged in SAP S/4HANA - this remains foundational Materials Management configuration rather than something restructured by the simplified data model. S/4HANA users can post returns through the same MIGO transaction in SAP GUI, or through the Fiori "Post Goods Movement" app, which reads the same underlying OMJJ configuration, so the fix in this guide applies identically regardless of which interface is used to post the return.

🔗 Cross-Module Impact: How a 161 Return Touches FI and Procurement

Although movement type 161 is posted through MM, it has direct downstream effects in both Financial Accounting and the original purchasing document. On the FI side, a 161 posting typically generates a debit memo relevant document reducing the amount owed to the vendor, following the same account determination logic (OBYC, transaction key BSX and related keys) as the original goods receipt, just in reverse. On the procurement side, the return reduces the "delivered quantity" tracked against the original purchase order line, which can affect purchase order history reporting, open quantity calculations for any remaining expected delivery, and in some cases retroactively affect invoice verification if the vendor's invoice hasn't yet been processed.

Because of this cross-module reach, a genuinely large or unusual return - particularly one crossing a period boundary, as covered in a related guide on this site about MM period closing - is worth coordinating with the accounts payable team before posting, since the resulting financial adjustment needs to land in the correct, currently open period alongside the original transaction it's reversing.

📋 Related SAP Transactions

🎓 Interview-Style Questions and Answers

Q: What is the purpose of movement type 161, and how does it differ from 122?
161 is a Return to Vendor posted with reference to the original purchase order, reducing the delivered quantity on that PO. 122 is a return without a PO reference, used when no formal purchasing document exists to reference, such as for free samples.

Q: Why would SAP block a movement type even though it's a standard, valid SAP movement type?
Because OMJJ's Allowed Transactions configuration deliberately restricts which specific transactions can post each movement type - a movement type being valid in SAP generally doesn't mean it's been explicitly enabled for every transaction in a given system.

Q: If a new plant's receipts and issues work fine but returns fail with this error, what's the likely cause?
The movement type configuration copy used to set up the new plant likely didn't include the Allowed Transactions entry for 161, often because return-to-vendor wasn't part of initial go-live testing, which typically focuses on higher-frequency receipt and issue processes.

📚 Quick Glossary of Terms Used in This Guide

• Movement type: A three-digit code in SAP defining the nature of a stock movement, such as 161 for a PO-referenced return to vendor.
• OMJJ: The SAP configuration transaction for maintaining movement types, including which transactions are allowed to post each one.
• Allowed Transactions: The specific configuration within OMJJ controlling which transactions (e.g. MIGO, MB1C) can post a given movement type.
• Return to Vendor: The business process of sending previously received goods back to a supplier, typically due to damage, quality issues, or excess quantity.
• GR Returns: Another common name for movement type 161, reflecting that it's the reversal counterpart to the original goods receipt (movement type 101).
• Debit memo: The financial document typically generated by a return posting, reducing the amount owed to the vendor for the returned quantity.

🎯 Conclusion

"Movement type 161 is not allowed" almost always comes down to one thing: 161 hasn't yet been added to the Allowed Transactions list for MIGO (and sometimes MB1C) in OMJJ, most often because a new plant's setup never explicitly tested the return-to-vendor process. Adding the missing entries resolves it in minutes. Keep this guide bookmarked for the next time a new plant or company code hits this error on its first real return.