SAP Taxes

FI determines the tax on transactions (e.g. VAT on a vendor invoice or customer billing) using tax codes and procedures, posts it to the correct tax accounts, and supports tax reporting/returns. It handles country-specific rules, which vary widely, so tax configuration is inherently local and detailed.

• Tax codes: encode the rate and account determination.
• Tax procedures: the country-specific calculation logic.
• Input vs output tax: on purchases vs sales.
• Withholding tax for certain payments.

The tax procedure is worth naming as well. It is assigned per country and defines which condition types apply and in what order, in the same condition technique used for pricing. Tax codes then sit inside that procedure. This is why a new country is not simply a new tax code: it needs its procedure assigned and its accounts determined before anything can post.

Tax rarely gets typed. It is determined, and the determination differs between buying and selling, which is the first thing to hold clear.

On the purchasing side, the tax code comes from the purchase order item, where it can be defaulted from the info record, the material or the vendor. Invoice verification then uses it, or determines it itself if the invoice says something different.

On the sales side, tax is a condition in the pricing procedure and is determined by the condition technique, from the tax classification on the customer master, the tax classification on the material master, and the countries of the departure point and the destination.

That last part is what makes cross-border sales interesting. Shipping from one country to another changes the tax treatment entirely, and the determination has to know both ends, which is why the plant's country and the ship-to party's country both matter and why using the wrong ship-to produces the wrong tax.

The tax code itself encodes the rate and, through configuration, which general ledger accounts the tax posts to. It is defined per country, so the same two-character code means different things in different countries.

Twenty minutes, and it shows input and output tax as the mirror images they are.

1. Post a vendor invoice with FB60, entering a tax code and letting the system calculate the tax amount.
2. Open the document. There are three lines: expense, tax and payable. The tax line went to an input tax account, and it is recoverable, which is why it is an asset rather than a cost.
3. Post a customer invoice with FB70 using an output tax code.
4. Compare. Receivable, revenue and a tax line to an output tax account, which is money owed to the authority.
5. Run the tax report for the period. Input and output are reported together, and the difference is what is paid or reclaimed.

Step two is the point most people miss: input tax is not an expense. Treating it as one overstates costs and understates what can be reclaimed.

Tax is determined in MM (purchasing) and SD (sales) and posted through FI. External tax engines (e.g. for complex US sales/use tax) can be integrated. Tax reporting produces the returns authorities require, an area of constant regulatory change, so staying current matters.

Reporting is where tax configuration is judged. The periodic return is produced from the postings, so a wrong tax code is not merely an accounting error, it is a filing error. Increasingly the filing is electronic and mandated in a specific format, which turns tax from a configuration exercise into a compliance obligation with deadlines. See the general ledger for where the accounts are defined.

• Native tax determination or an external engine. Configuration in SAP works well for a handful of countries. Businesses selling into many jurisdictions usually connect a specialist engine that maintains the rates for them.
• How many tax codes. One per rate and treatment combination per country. It grows quickly, and a naming convention decided at the start saves a great deal later.
• Who maintains rates. They change by legislation, and somebody has to notice. Where an external engine is used, that is its job; where it is not, it is a person's.
• Plants abroad and registrations. Selling into a country may create a registration obligation there, which changes the configuration and is a tax advice question rather than a system one.

Domestic sales at a single rate are straightforward. Everything else is where the configuration earns its keep.

Reverse charge. On certain cross-border and domestic transactions the buyer accounts for the tax rather than the seller. The invoice carries no tax and the buyer posts both an input and an output entry that net to zero, which looks strange the first time you see it and is correct.

Intra-community supply. Selling between EU member states to a registered business is zero-rated, and the buyer accounts for it. The determination depends on both parties' registration numbers being present and valid, which is why a missing VAT number on a customer master stops an invoice.

Non-deductible input tax. Some purchases do not allow full recovery, so part of the tax becomes cost and is posted to the expense rather than the tax account. Entertainment and certain vehicles are the usual examples.

Plants abroad. Where a company operates in a country without a separate legal entity, it may still be registered there for tax, and postings must carry the right country's treatment.

Withholding tax. The payer deducts tax from a supplier payment and remits it directly. It is configured separately from the transaction tax above and it appears at payment rather than at invoice.

Each of these is a business decision documented by a tax adviser and then configured. The consultant's job is asking which apply, not deciding them. See bank accounting for where withholding surfaces at payment.

Three recurring patterns, worth recognising early.

Codes created per requirement rather than per treatment. Somebody needs a new rate, so a code is added, and within two years there are forty codes where twelve treatments exist. Nobody can say which to use, so people guess, and the return is built on guesses.

Determination left manual "for now". Entering the tax code by hand works and puts the decision on whoever raises the document. It is the fastest route to inconsistent treatment of identical transactions.

Rates maintained by nobody. Legislation changes, and unless somebody owns watching for it, the system carries yesterday's rate until an accountant notices. Where an external tax engine is used this is its job; where it is not, it needs a name against it.

The common thread is that tax configuration decays unless it is owned. It is not a build-once activity, and treating it as one is why tax findings appear in audits of otherwise well-run systems.

• Wrong tax code, wrong rate/account.
• Ignoring country-specific rules.
• Tax reporting not matching postings.

• Treating input tax as a cost. It overstates expense and hides a reclaim.
• One tax code reused across countries. The code is country-specific; the same characters mean different rates elsewhere.
• Ignoring the ship-to country on cross-border sales. See FI troubleshooting for diagnosing the resulting postings.

Posting with a tax code is the easy half, and configuring determination and account assignment so a return can be filed from the system is the part you do in the course.

The rule worth carrying is that input tax is an asset and output tax is a liability. Anything that posts tax to an expense account should be deliberate, because it means somebody decided the tax is not recoverable.