Scenario 24 — Withholding Tax (FBR Section 153 on Vendor Payments)
📊 Business Case
Withholding Tax (WHT) is income tax that the buyer deducts from the vendor's payment and remits to the government on the vendor's behalf. Under Pakistan's FBR Income Tax Ordinance Section 153, PakSteel is legally obliged to withhold tax at source on payments to suppliers — paying the vendor the net amount and depositing the deducted tax with the FBR via challan. This is legal compliance: miss it and the company is liable for the tax plus penalties. SAP must auto-calculate and post both legs.
🕐 When to use it
On every payment to a vendor that falls under Section 153 — goods, services, and contracts — once WHT is configured and the vendor is flagged as liable.
❓ Why it matters
It is a statutory obligation. The withholding agent (PakSteel) must deduct correctly by category and filer status, and remit to FBR — or face recovery and penalties. SAP automates the calculation so it's never missed.
👤 Who triggers it
FI/AP runs the invoice and payment; the WHT is calculated automatically by SAP. The tax team reconciles the WHT-payable account and files the monthly challan with FBR/NBP.
🔁 The key distinction
Classic vs Extended WHT. Classic calculates only at payment (F-53/F110). Extended (recommended, and what PK uses) can calculate at invoice posting and/or payment — more flexible and the S/4 default.
💰 Financial Impact — The Easy-Money Example
PakSteel owes Mughal Steel PKR 1,000,000 for goods (the vendor is a tax filer, so the Section 153 goods rate is 4.5%). The total expense is unchanged — but the cash splits in two: part to the vendor, part to FBR.
The big idea: the vendor's liability is the full PKR 1,000,000, but PakSteel splits the settlement — PKR 955,000 cash to the vendor and PKR 45,000 to FBR. The WHT-payable account is the bridge: credited when the invoice posts, debited when the tax is remitted. The company is merely a collection agent for the government.
🇵🇰 The Business Story
🎯 What you'll learn
- Classic WHT: calculated at payment time only (F-53/F110). Older method.
- Extended WHT (recommended): calculated at invoice posting AND optionally at payment. Modern flexibility — what Pakistani implementations use.
- SAP S/4 fully supports both; Extended is the default.
- How WHT types and codes encode the FBR category and filer/non-filer rate
- How the WHT-payable liability is built at invoice and cleared at monthly remittance
- A vendor to pay — e.g. MUGHAL21 — and you know whether it is an FBR filer or non-filer (see BP Create Guide).
- Company code PSPK with core FI settings already live (see Setup Hub).
- Customizing access on a sandbox (SPRO / FBKP / FK02) — activating Extended WHT and flagging the vendor "Liable" are done inside this scenario.
🔧 Step-by-Step — Config Steps
| Step | T-code | What it does | Why this step exists |
|---|---|---|---|
| 24.1 | FBKP / SPRO | Turn Extended WHT on for company PSPK | the law cannot run until the machinery is on |
| 24.2 | SPRO | Create the FBR rate cards — types P1–P4, codes like 153G 4.5% | SAP needs the legal rates in a readable form |
| 24.3 | SPRO | Let company PSPK use the rate cards from a start date | country-level cards must be signed up per company |
| 24.4 | SPRO | Name G/L 160500 as the "FBR jar" for deducted tax | every deducted slice needs a place to wait |
| 24.5 | FK02 / BP | Stamp P1 / 153G and "Liable" onto vendor MUGHAL21 | tax is applied vendor by vendor, not to everyone |
| 24.6 | MIRO | Post the invoice — SAP auto-cuts 45,000 into the jar | deduction must run from config, not clerk memory |
| 24.7 | F-53 | Pay the vendor only the net 955,000 | the tax slice was already kept at invoice time |
| 24.8 | F-02 | Deposit the jar's 45,000 to FBR and clear the liability | the withheld money was never the company's own |
24.1 — Activate Extended WHT · FBKP / SPRO
⚡ This step will: switch the Extended WHT machinery ON for company code PSPK — after this, SAP is able to deduct tax at invoice time, but no rates exist yet. 📄 paper: — · 📦 stock: no change · 💰 money: no posting
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| Path | SPRO → FI → FA Global Settings → Withholding Tax → Extended WHT | Where does this setting live? It sits under FI (Financial Accounting), not MM, because deducting tax is an accounting job. | "Extended" is the modern branch that can deduct already at invoice time. Impact: configure the old "Classic" branch instead and you lose invoice-time deduction and multiple WHT types per vendor |
| WHT Country | PK | Under WHICH country's tax law does this run? WHT rules differ by country. | PK is Pakistan's rule book (FBR) — the rates defined next all belong to it. Impact: the wrong country and your FBR rates attach to the wrong legal framework, so they never apply to Pakistani postings |
| Activate Extended WHT | for CC PSPK | Which COMPANY switches the machinery on? Activation is per company code. | Turning it on for PSPK means every vendor invoice in that company checks the vendor's WHT tab before posting. Impact: not activated and no tax is ever withheld — PakSteel breaks its legal Section 153 duty and faces penalties |
24.2 — Define WHT Types & Codes
⚡ This step will: create the FBR rate cards inside SAP — types P1–P4 with codes like 153G at 4.5% — but nothing is deducted yet, because no vendor points at them. 📄 paper: — · 📦 stock: no change · 💰 money: no posting
Two-level idea: the type is the drawer ("goods tax, deducted at invoice"); the code is the exact rate card inside it. Together they turn the FBR rate table into something SAP can read.
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| WHT Type (the drawer — WHEN and which category) | |||
| WHT Type | P1 (Pakistan Goods – Filer) | A "drawer" for one FBR category of payment — here, goods paid to a tax filer. | One type per category keeps the rules tidy and separately reportable. Impact: lump categories into one type and you cannot report goods vs services tax separately for the FBR return |
| Country | PK | Which country's WHT law this type belongs to. | Ties the type to Pakistan's FBR framework activated in 24.1. Impact: a wrong country and the type is not recognised for Pakistani company postings |
| Calculation point | Calc at Invoice | WHEN is the slice cut — when the bill is posted, or when cash is paid? | "At invoice" is the Extended-WHT strength: the liability is recorded the moment the bill posts, matching Pakistani practice. Impact: set it to payment-time only and the WHT liability is missing between invoice and payment, distorting month-end figures |
| WHT Code (the rate card inside the drawer) | |||
| WHT Code (under P1) | 153G | The exact "rate card" inside the type. Its name echoes FBR Section 153, Goods. | A law-echoing code makes the config readable and auditable. Impact: a meaningless code makes it hard to prove which legal rate a vendor was charged |
| Rate (percentage) | 4.5% | Exactly HOW MUCH is cut — the withholding percentage. | 4.5% is the Section 153 goods rate for a filer, so a PKR 1,000,000 bill withholds PKR 45,000. Impact: a wrong % deducts too much (angering the vendor) or too little (leaving PakSteel liable to FBR for the shortfall) |
| Repeat for other categories | P2/153G-NF 9% · P3/153S 8% · P4/153S-NF 16% | Why FOUR? One card per FBR category × filer status (goods/services, filer/non-filer). | Non-filers pay double — FBR's push to register; which card applies to a vendor is decided later on the vendor master (24.5). Impact: miss a card and vendors in that category cannot be taxed at the correct legal rate |
| Save | — | Stores the rate cards. | The cards now exist, but nothing is deducted yet because no vendor points at them. Impact: unsaved, the later vendor assignment (24.5) has nothing to choose from |
24.3 — Assign WHT to Company Code
⚡ This step will: give company PSPK the right to actually USE the P1–P4 rate cards from a start date — the cards go from "defined" to "usable". 📄 paper: — · 📦 stock: no change · 💰 money: no posting
Do: assign WHT Types P1–P4 to CC PSPK with a validity period.
Asks: which company may USE these drawers, and from when? Types are defined for the country; each company code must still sign up for the ones it applies. The validity period = the from-date the rule is in force — rate changes later get a new period instead of overwriting history.
24.4 — Assign WHT G/L Accounts
⚡ This step will: name the "FBR jar" — G/L account 160500 — so every deducted tax slice has a place to sit until it is handed to the government. 📄 paper: — · 📦 stock: no change · 💰 money: no posting
Do: set the WHT Payable to FBR liability G/L: 160500 (or your CoA equivalent).
Asks: WHERE does the deducted slice wait until FBR gets it? Think of a separate jar labelled "FBR's money — not ours". Every invoice drops its 4.5% into this jar (credit); the monthly challan payment empties it (debit, step 24.8). Without an account here, SAP would compute the tax but have nowhere to post it.
24.5 — Assign WHT to Vendor Master · FK02 or BP
⚡ This step will: stamp the tax onto vendor MUGHAL21 — from now on every invoice for this vendor auto-deducts 4.5%, with no clerk action needed. 📄 paper: — · 📦 stock: no change · 💰 money: no posting
Config so far built the rate cards. This step decides who they apply to — tax is stamped on the vendor, one by one.
| Section · Field | Fill | What the field asks (plain words) | Why we choose this — and the impact if wrong |
|---|---|---|---|
| BP / FK02 · Vendor | MUGHAL21 (Mughal Steel — filer) | Which supplier are you stamping the tax onto? | Tax is applied vendor by vendor, so you open the exact vendor to tax. Impact: stamp the wrong vendor and the right one is never taxed while an innocent one is |
| Company code | PSPK | WHT data lives in the vendor's company-code part — which company's dealings with this vendor? | The same vendor could be taxed differently by another company, so the setting is per company code. Impact: maintain it under the wrong company code and PSPK's invoices still deduct nothing |
| Withholding Tax tab | |||
| WHT Type | P1 | Which drawer (category) applies to this vendor? | Mughal supplies goods, so the goods type P1 fits. Impact: the wrong type applies another category's rules (e.g. services), mis-taxing the payment |
| WHT Code | 153G | Which rate card inside that drawer — i.e. which exact rate? | Mughal is a filer, so the 4.5% goods card (153G) is correct. Impact: the wrong code deducts the wrong percentage automatically on every invoice |
| Liable (tick) | ✓ | Is tax actually deducted from THIS vendor at all? The per-vendor master switch. | No tick means no deduction, however perfect the rest of the config. Impact: forget the tick and Mughal's invoices pay the full amount to the vendor and nothing to FBR — a compliance breach |
| Save · non-filers | assign P2/153G-NF instead | What changes for a non-filer vendor? Only the card — the 9% one. | Once the right card is on the vendor, SAP applies the correct rate automatically with no decision at invoice time. Impact: leave a non-filer on the 4.5% card and PakSteel under-deducts, becoming liable to FBR for the shortfall |
24.6 — Post Invoice → WHT auto-calculated
⚡ This step will: record the vendor's bill with the tax slice already cut — Mughal's open item is born as the NET 955,000, and 45,000 drops into the FBR jar. 📄 paper: invoice document · 📦 stock: no change · 💰 money: Dr Inventory/GR-IR 1,000,000 · Cr Vendor 955,000 · Cr WHT Payable 45,000
A normal MIRO invoice (same zones as Scenario 6 — Transaction dropdown, Basic Data Amount, PO Reference tab, Balance), with one extra header tab to glance at: the Withholding Tax tab, which SAP fills by itself.
| Step · Where on screen | What you do / see | Why (what it asks / what it proves) |
|---|---|---|
| 1 · Header · Basic Data tab | vendor MUGHAL21 · amount PKR 1,000,000 (Goods) | A completely normal invoice entry — the clerk does nothing special. That is the point: the law runs from config, not from memory |
| 2 · Header · Withholding Tax tab | shows Base 1,000,000 · WHT 45,000 (4.5%) | Asks: on WHAT amount, and HOW MUCH is cut? Both auto-filled from the vendor's rate card (24.5). Check the tab before posting — wrong card on the vendor shows up here first |
| 3 · Toolbar · Post | — | One document posts both legs — vendor gets the net, the FBR jar gets the slice (see below) |
Accounting:
| Inventory / GR/IR Dr | 1,000,000 |
| Vendor Cr | 955,000 |
| WHT Payable to FBR (160500) Cr | 45,000 |
24.7 — Pay Vendor — only Net 955,000 · F-53
⚡ This step will: pay the net debt — Mughal's 955,000 open item clears and the bank shrinks. No tax maths here: the tax was already cut at invoice (24.6). 📄 paper: payment document · 📦 stock: no change · 💰 money: Dr Vendor 955,000 / Cr Bank 955,000
Do: F-53 → fill Header + Bank data → type the vendor in Open Item Selection → click Process open items → double-click the 955,000 item so it turns blue (assigned) → check the balance shows 0 → Post.
| Where on screen · Field / Action | Fill | What it asks (plain words) | Why — and the impact if wrong |
|---|---|---|---|
| Header (top) · Document/Posting Date · Company Code | today · PSPK | When is the payment dated, and for which company? | Dates the cash movement in PSPK's books. Impact: a wrong company code hits the wrong ledger. |
| Bank data area · Account | your house-bank outgoing G/L | Which bank account does the money LEAVE from? | This G/L is credited — cash goes out. Impact: the wrong bank G/L credits the wrong account. |
| Bank data area · Amount | 955,000 | How much cash actually leaves? | Only the NET — the 45,000 WHT was already withheld at invoice (24.6). Impact: type 1,000,000 and you overpay the vendor the tax you already kept for FBR. |
Open item selection area · Account (type K) | MUGHAL21 | Whose unpaid bills should SAP list? | Lists Mughal's open items so you can pick the one to settle. Impact: the wrong vendor shows the wrong bills. |
| Process open items screen · pick the item | double-click the 955,000 line (goes blue) · balance 0 | Which bill is this payment clearing? The assigned amount must equal the bank amount. | Balance 0 = the cash exactly matches the chosen open item. Impact: a non-zero balance blocks the Post — you left an item unassigned or over/under-paid. |
What changes at this exact moment:
| Vendor MUGHAL21 | Dr 955,000 | the open item is cleared — Mughal's bill status flips Open → Cleared |
| Bank (outgoing G/L) | Cr 955,000 | cash physically leaves PakSteel |
The difference to notice: in the textbook "classic" case, F-53 is where WHT is deducted. Here it is NOT — because this scenario uses Extended WHT calculated at invoice (24.2), the open item was already born as 955,000 in 24.6. So payment has no tax leg and no tax maths — it just moves the net cash. The 45,000 still sits in the FBR jar (160500), waiting for 24.8.
24.8 — Monthly WHT Remittance to FBR — manual JV
📄 paper: accounting (JV) document · 📦 stock: no change · 💰 money: Dr WHT Payable (160500) 45,000 / Cr Bank 45,000
Do: manual FI posting (F-02): WHT Payable Dr / Bank Cr → clears the WHT liability after the challan deposit at NBP.
What this step IS: emptying the FBR jar. All month the jar (G/L 160500) collected slices from every invoice; the challan deposit hands them to the government, and this posting clears the liability. The company was only the collection agent — the money was never PakSteel's.
What changes at this exact moment (for our one PKR 1,000,000 invoice; in reality the whole month's slices go at once):
| WHT Payable to FBR (160500) | Dr 45,000 | the FBR jar is emptied — the liability is gone |
| Bank | Cr 45,000 | cash deposited to FBR via the NBP challan |
Full circle: 160500 was credited 45,000 when the invoice posted (24.6) and is now debited 45,000 here — net zero. PakSteel was only ever the collection agent; the money was never its own.
✅ Verification
| # | T-code | Check |
|---|---|---|
| 1 | FK03 / BP | Vendor MUGHAL21 Withholding Tax tab shows Type P1 / Code 153G, Liable ✓ |
| 2 | FB03 | Invoice document shows Vendor Cr 955,000 and WHT Payable (160500) Cr 45,000 |
| 3 | FBL1N | Mughal Steel open item is 955,000 (already net of WHT) |
| 4 | FBL3N | WHT Payable G/L 160500 accumulates the 45,000 credit; cleared after the F-02 remittance |
| 5 | S_P00_07000134 | Generic withholding tax report — WHT base and amount per vendor for the FBR challan |
🎓 Interview-Ready Answers
Q: What is the difference between Classic and Extended Withholding Tax?
Classic WHT calculates only at the time of payment (F-53/F110) and allows just one WHT type per vendor line. Extended WHT can calculate at invoice posting and/or payment, supports multiple WHT types simultaneously, and handles WHT base, formulas and certificates. Extended is the modern, recommended approach and the S/4HANA default — Pakistani implementations use it for Section 153.
Q: Walk me through the accounting when you post a PKR 1,000,000 goods invoice for a filer.
At a 4.5% filer rate the WHT is 45,000. The posting is: Inventory/GR-IR Dr 1,000,000, Vendor Cr 955,000, and WHT Payable to FBR Cr 45,000 (G/L 160500). The vendor's open item is the net 955,000; the 45,000 is parked as a liability until remitted to FBR.
Q: Why do filers and non-filers have different rates, and how does SAP know which to apply?
FBR charges non-filers a higher rate (e.g. goods 9% vs 4.5%) to push registration. In SAP this is encoded as different WHT codes under the WHT type — 153G at 4.5% for filers, 153G-NF at 9% for non-filers. The correct type/code is assigned in the vendor master Withholding Tax tab, so SAP applies the right rate automatically based on which code the vendor is flagged with.
Q: How is the withheld tax actually paid to the government?
The WHT-payable account (160500) accumulates all deductions during the month. The tax team files a monthly challan and deposits the tax at NBP; a manual FI posting (F-02) then debits WHT Payable and credits Bank, clearing the liability. SAP's withholding-tax report provides the per-vendor figures for the challan.