SAP Error: No Taxes on Sales/Purchase Allowed for This Account
The error "No taxes on sales/purch. are allowed for account [X], tax code [Y] is not allowed" appears when a G/L account's Tax Category field is set to blank or "not allowed," but a transaction in FB50, FB60, or MIRO is trying to apply a tax code against it. This guide covers both fix options - updating the account's tax category, or removing the tax code from the transaction - then explains how MIRO's automatic tax code inheritance often triggers this without the user manually entering anything. If you encounter any errors in SAP, feel free to send a screenshot to pramod@learntosap.com for help.
✅ Error Cause
The G/L account is configured with Tax Category = "Not allowed" or blank. At the same time, during posting, the system is trying to use a specific tax code (such as F1) against that account. This creates a direct conflict, and SAP raises the error rather than posting an inconsistent document.
In short: the G/L account master controls whether tax posting is allowed on that account at all, while the tax code (like F1) is what a specific transaction (FB60, MIRO, FB50) is actually trying to use - and the two need to agree before the posting can succeed.
🔧 Solution 1: Update the G/L Account's Tax Category (FS00)
Go to transaction FS00 and open the relevant G/L account.
Select the Control Data tab.
Set the Tax Category field: * for all tax types allowed, + for input tax only, or - for output tax only.
Save.
🔧 Solution 2: Remove the Tax Code From the Transaction
If tax genuinely isn't required for this posting, using FB50, FB60, or MIRO, simply remove the tax code (for example F1) from the transaction and save. This is the correct fix when the account should legitimately stay tax-free and the tax code was applied by mistake or defaulted incorrectly.
🔍 Which Fix Should You Actually Use?
This error has two valid fixes, and picking the wrong one is a genuinely common mistake - the correct choice depends entirely on which side of the conflict reflects business reality. If the account genuinely should support tax-relevant transactions (a purchase or sales-related expense/revenue account, for instance), the G/L account's Tax Category is the misconfigured side, and Solution 1 is correct. If the account is something that should never carry tax - an internal clearing account, certain non-taxable expense categories, or a specific G/L account your organization's finance team has deliberately excluded from tax reporting - then the transaction is the misconfigured side, and Solution 2 (removing the tax code) is correct.
Changing the wrong side creates its own problem: enabling tax on an account that should stay tax-free can result in incorrect tax reporting down the line, while stripping a tax code from a transaction that genuinely needed it can under-report tax liability. When in doubt, this is exactly the kind of decision worth a quick check with your finance/tax team rather than guessing, since the "right" answer depends on business and regulatory context this guide can't determine for your specific account.
📋 The Tax Category Field, Explained in Full
| Value | Meaning | Typical Use |
|---|---|---|
| (blank) | No tax allowed on this account at all | Internal clearing accounts, accounts deliberately excluded from tax-relevant postings |
| * | All tax types allowed (both input and output) | General expense/revenue accounts used across varied tax scenarios |
| + | Only input tax allowed (tax paid on purchases) | Purchase-related expense accounts |
| - | Only output tax allowed (tax charged on sales) | Sales-related revenue accounts |
| A specific tax code | Only that exact tax code is allowed, no others | Highly specific accounts tied to one particular tax scenario |
This field exists as a deliberate control, not an incidental setting - it lets an organization's finance team enforce which accounts are permitted to carry which categories of tax, catching a misapplied tax code before it becomes a reporting or compliance problem, rather than after the fact during a tax filing review.
💰 Why This Often Appears in MIRO Without the User Choosing a Tax Code
A detail that confuses many users the first time they hit this error: they never manually selected a tax code, yet the error names one specifically (like F1). This is because MIRO typically defaults the tax code automatically from the referenced purchase order - which in turn usually inherits its own tax code from the vendor master's tax classification, or from a default set at the material or purchasing info record level. By the time a user opens MIRO to verify an invoice, a tax code may already be populated on the screen without them having touched it.
If that inherited tax code conflicts with the G/L account's Tax Category configuration (perhaps because the invoice is being posted against an account not usually used for this vendor or material type), the error appears exactly as if the user had chosen it manually. Understanding this chain - vendor/PO tax code default, flowing into MIRO, checked against the G/L account's Tax Category - helps explain why the fix sometimes needs to happen further upstream (correcting the vendor's or material's tax classification) rather than just adjusting the immediate MIRO screen or the G/L account each time this comes up.
💼 Real-World Scenario: A Freight Clearing Account Never Meant to Carry Tax
Priya Mehata, an SAP FI support analyst, received a ticket from an accounts payable clerk unable to post a vendor invoice in MIRO - the system kept rejecting it with "No taxes on sales/purch. are allowed for account 110002 1003, F1 is not allowed." The clerk hadn't touched the tax code field at all; it had simply appeared pre-filled when the invoice screen loaded.
Investigating, Priyafound that account 110002 was a freight clearing account, deliberately configured with a blank Tax Category since freight charges at this company were handled through a separate tax treatment elsewhere in the process and this particular clearing account was never meant to carry a tax posting directly. The real issue wasn't the G/L account - it was that the vendor's tax classification had recently been updated (as part of an unrelated master data cleanup project) to default tax code F1, which was now flowing through to every PO and MIRO invoice for that vendor, including this specific freight-related line that should never have carried a tax code at all.
Rather than changing the freight account's Tax Category (which would have incorrectly opened it up to tax postings it was never designed to carry), Priya worked with the clerk to simply remove the F1 tax code from this specific MIRO line - Solution 2 in this guide - and flagged the vendor's tax classification default for review with the master data team, since other invoices for that vendor might be affected by the same unintended default going forward. This scenario is a good illustration of the "which fix should you use" guidance earlier in this guide: the account was correctly configured, and the actual root cause was upstream in vendor tax classification defaults flowing into MIRO.
❗ Common Mistakes When Fixing This Error
- Reflexively changing the G/L account's Tax Category to * without checking whether the account was deliberately configured to exclude tax for a genuine business reason.
- Removing the tax code from a transaction without investigating why it appeared in the first place, potentially masking a vendor or material tax classification issue that will keep recurring on other transactions.
- Not consulting with finance/tax before changing tax-relevant configuration, given the compliance implications of either fix.
- Assuming the user manually selected the conflicting tax code, when in MIRO it's frequently inherited automatically from the PO/vendor, as covered earlier in this guide.
- Fixing the symptom on one transaction without checking whether the same root cause (an incorrect vendor tax classification, for example) will affect other pending or future postings too.
✅ Prevention Checklist for FI/MM Configuration Teams
- Document the intended Tax Category for every G/L account as part of standard chart-of-accounts documentation, so future reviewers understand whether a blank or restricted category is deliberate.
- Review vendor tax classification changes for downstream impact before applying them broadly, since a single vendor master update can affect every future PO and invoice for that vendor.
- Test a representative MIRO posting after any vendor tax classification change, confirming the inherited tax code doesn't conflict with commonly-used G/L accounts for that vendor.
- Coordinate G/L account tax category changes with the finance/tax team, given the compliance and reporting implications either fix can carry.
- Periodically audit G/L accounts with a blank Tax Category against actual recent posting attempts, to catch accounts that are increasingly being used in ways their original tax configuration didn't anticipate.
📱 This Error in SAP S/4HANA
The Tax Category field and its interaction with tax codes during posting are unchanged in SAP S/4HANA, since this is foundational Financial Accounting configuration rather than something restructured by the Universal Journal. G/L account maintenance can be done via the classic FS00 transaction or the Fiori "Manage G/L Account Master Data" app, both reading and writing the same underlying Tax Category configuration, so the fix in this guide applies identically regardless of interface.
🔗 Cross-Module Impact: How This Touches MM and Vendor Master Data
Although this error surfaces as a Financial Accounting posting block, its trigger frequently originates in Materials Management - specifically vendor tax classification and purchase order tax code defaults, as covered in the MIRO inheritance section above. This means resolving a recurring instance of this error sometimes requires MM and FI teams to coordinate: FI can confirm whether the G/L account's Tax Category is correctly configured, while MM/procurement needs to confirm whether the vendor's tax classification (and any resulting PO tax code default) genuinely reflects that vendor's real tax situation.
This is particularly relevant for organizations with vendors spanning multiple tax jurisdictions or a mix of taxable and non-taxable goods/services, where a single vendor master tax classification default may not correctly apply to every transaction type that vendor is used for - exactly the pattern in the real-world scenario above, where a freight-related posting inherited a tax code intended for a different category of purchase from the same vendor.
📋 Related SAP Transactions
| Transaction | Purpose |
|---|---|
| FS00 | Maintain G/L account master data, including the Tax Category field. |
| FB50 | Post a G/L account document directly in Financial Accounting. |
| FB60 | Post a vendor invoice directly in Financial Accounting. |
| MIRO | Post a vendor invoice with reference to a purchase order, in Materials Management. |
| FTXP | Maintain tax codes and their associated tax rates and G/L account determination. |
| XK02 | Change a vendor master record, including its tax classification. |
🎓 Interview-Style Questions and Answers
Q: What controls whether a G/L account can carry a tax posting?
The Tax Category field on the G/L account's Control Data view (maintained in FS00), which can be blank (no tax allowed), * (all tax types), + (input tax only), - (output tax only), or restricted to one specific tax code.
Q: Why might this error appear in MIRO even though the user never entered a tax code?
MIRO typically defaults the tax code automatically from the referenced purchase order, which in turn usually inherits it from the vendor master's tax classification - meaning the conflict can originate upstream in master data rather than from a manual user selection.
Q: How would you decide whether to fix this by changing the G/L account or removing the tax code from the transaction?
Determine which side reflects business reality - if the account should genuinely support this kind of tax-relevant posting, update its Tax Category; if the specific transaction genuinely shouldn't carry tax, remove the tax code instead, ideally after confirming with finance/tax.
📚 Quick Glossary of Terms Used in This Guide
- Tax Category: A G/L account master field controlling whether, and which type of, tax postings are allowed on that account.
- Input tax: Tax paid on purchases, typically reclaimable depending on jurisdiction and business type.
- Output tax: Tax charged on sales, typically owed to the tax authority.
- Tax code: A configured code (such as F1) representing a specific tax rate and posting behavior, maintained in FTXP.
- Tax classification: A vendor or customer master setting influencing which tax code defaults onto transactions involving that business partner.
- Control Data: The G/L account master view containing the Tax Category field alongside other posting-control settings.
🎯 Conclusion
"No taxes on sales/purch. are allowed for account X, tax code Y is not allowed" comes down to a genuine conflict between a G/L account's Tax Category configuration and the tax code a transaction is trying to apply. Resolving it correctly means figuring out which side actually reflects business reality - updating the account in FS00, or removing the tax code from the transaction - rather than defaulting to whichever fix seems fastest. Keep this guide bookmarked, and remember to trace MIRO tax code conflicts back to vendor tax classification when the user never entered one manually.