A tax consultant is only as strong as the hand-offs around them. On this programme I sit between four parties, each a clean interface — select a counterpart to see what flows each way.
My value is the join between the legal requirement (from the Tax SME) and the working system — configured by me, built by ABAP, used through MM / SD / FI.
This is where the hours actually go — the working surface of an FI tax consultant. Open any pillar for the concrete activities and the transactions behind them.
I build the engine that calculates and posts tax: the Thai calculation procedure TAXTH, tax codes and their rates/types in FTXP, the account determination that routes each tax transaction key to a GL account in OB40, and the GL master settings in FS00. For withholding, define Extended WHT types and codes in SPRO and link them to master data.
I make sure the right tax lands on the right document. Tax flows in from MM (the tax code on a purchase order / invoice verification), SD (output tax via condition records), and direct FI postings (FB60 vendor invoice, FB70 customer invoice). I verify input vs. output VAT splits and that WHT is withheld at payment.
I produce what the Revenue Department wants to see. Output VAT − input VAT is filed monthly on PP30 (data from the VAT report, e.g. RFUMSV00); withholding is filed on PND 3 / 53 / 54 with WHT certificates. On S/4HANA this increasingly runs through DRC / Advanced Compliance Reporting — worth knowing by name.
The configuration only works if the master data carries the right tax attributes: tax classification on customer / vendor / material, the Extended WHT type & code assigned on the vendor master, VAT registration numbers, and the tax category on the GL master. I define the rules; data migration loads the volume.
I prove the tax behaves. I unit-test each tax code, integration-test the end-to-end flows that carry tax (P2P with input VAT + WHT, O2C with output VAT, period-end VAT/WHT runs), write and walk test scripts, and support UAT. Log and triage tax defects with clear reproduction steps — the same UAT discipline I ran across four XeerSoft go-lives.
I get tax right at the switch. I validate open items that carry tax, opening tax balances, and any WHT carry-forward; confirm configuration transports moved correctly; and check the first live postings determine tax as designed. I support the tax slice of the cutover plan — I don't own the whole cutover.
I stabilise the first cycles. I support the first month-end VAT filing (PP30) and WHT filing (PND), reconcile the tax GL accounts, triage incidents on tax postings, and hand over clean knowledge-transfer docs so BAU / AMS can take it.
Petroleum-specific levies on the PTTEP client — Royalty, SRB, PITA — are not standard transactional tax codes. They land as GL provisions / period-end postings. My job is to make sure the right GL accounts and postings exist — not to own the legal computation. (See the companion page for the petroleum-tax detail.)
The tax solution is designed early and built & proven in the middle. I came in at late Realize, so my weight is on understanding the build, hardening it in test, and carrying it through cutover and run — not on the original design. Select a phase.
A consultant who can't name what's out of scope ends up owning everyone's problems. Here's what I deliver, what I deliberately hand off, and who is accountable for each — toggle the view.
The honest one-liner: I implement an agreed tax design and prove it works — I don't author the tax law or build the ABAP.
R Responsible (does the work) · A Accountable (owns the outcome) · C Consulted (gives input) · I Informed (kept in the loop). I'm Responsible for the build & proof; the Tax SME is Accountable for the law, the FI/CO Lead Accountable for delivery.
The artefacts that prove the work is done and auditable. Tick them off as a self-check — the count is held in memory only, nothing is saved.
When people ask which part of SAP FI I work on, this is the one-slide answer. Financial Accounting spans several sub-ledgers; tax is a layer that runs across them, anchored in Tax & Special Products. Select any node to see how it connects back to the tax engine I own.
↳ my branch — Tax & Special Products — expands to:
The transactions I reach for, what each one does, and where it sits in the build sequence. Filter by area.
A T-code is a shortcut; the real work is the SPRO customizing path and knowing which project phase each node belongs to. This is that tree for the Thai tax engine. Tap a branch to collapse it.
SPRO menu texts and phase mapping follow standard SAP FI customizing; exact node names vary slightly by release. The SPRO-only rows are maintained inside the IMG (no dedicated transaction shortcut).
I came onto the programme mid-stream — the design settled, the build under way. From here everything bends toward one fixed date: Go-Live in January 2027, with a hypercare tail behind it. Here is the programme month by month, and where I picked it up.
Dates are an illustrative plan — the live schedule is governed by the Accenture / PTTEP programme.
Two layers meet at PTTEP: the ordinary transactional taxes (VAT, WHT) that SAP FI computes on every document, and the petroleum levies (Royalty, SRB, PITA) that post as GL provisions. Open a row for the detail, then run the calculator to see the journal SAP would post.
A vendor (AP) invoice the way FB60 → F-53 posts it. Enter a base amount, pick VAT & a WHT type, and watch the tax and the journal compute live.
Standard illustrative rates: VAT 7%; WHT — services / professional 3%, rental 5%, transport 1%, advertising 2%, interest 1% (Thai PND 53 corporate payees). Petroleum levies follow the locked PTTEP figures and post as provisions, not transactional codes.
VAT & WHT post on every invoice. But PTTEP's real tax weight is the petroleum layer — Royalty · SRB · PITA — settled at period-end on profit, not per document. And Excise is a different animal entirely: a downstream, per-litre tax on refined products that never touches PTTEP's profit.
Excise is charged per litre and built into the price — the consumer bears it. It never touches PTTEP's profit. Downstream firms also pay normal CIT 20%.
The real PTTEP computation: Royalty and SRB are deducted first, then PITA is charged on the remaining petroleum profit. Government take = Royalty + SRB + PITA. (M฿ = million baht.)
Illustrative figures for learning — the real SRB uses a complex windfall formula (income per metre of well + a geological factor), not a flat rate. Royalty & SRB are deductible before PITA; interest is not. PTTEP's Bongkot / Erawan are PSCs (PITA 20%). In SAP these post as period-end GL provisions, never transactional tax codes.
The statutes and rules that become configuration decisions and test cases on a petroleum client. Open each for what it governs and the SAP implication I watch for.
Reference only — not legal or tax advice. Always confirm with the client Tax SME / advisor and current Revenue Department / DMF guidance before configuration.
PTTEP's programme is S/4HANA — a different Financial Accounting architecture from classic ECC. Knowing what actually changed isn't trivia; it's why the tax I configure is traceable in real time. Four shifts that matter most for an FI tax seat.
Separate FI (BKPF/BSEG), CO, ML and AA tables, reconciled at close.
One line-item table — ACDOCA. FI and CO merged, no reconciliation.
For taxevery VAT / WHT posting sits in one auditable line, drillable to its source document.
Separate vendor (XK01) and customer (XD01) masters.
A single Business Partner — one role-based master (mandatory in S/4).
For taxthe WHT type & code is assigned once on the BP, consistent across every role.
Parallel ledgers posted through period-end delta runs.
New Asset Accounting — parallel depreciation areas post in real time.
For taxasset & depreciation values align to the ledger with no separate delta step.
SAP GUI screens and batch-extracted reports.
Fiori apps + embedded analytics (CDS views) live on the Universal Journal.
For taxreal-time VAT / WHT views that drill straight to the document — no extract.
S/4HANA architecture is factual SAP platform knowledge; I present it as the ground I'm building on for this role, not as a system I have configured in production.
This isn't a one-consultant build. PTTEP's move to S/4HANA is a large, multi-year transformation that Accenture runs with a blended Thailand–India team across a dozen workstreams. Here's the rough shape of it, where I sit, and the value it's built to unlock.
Team size, shore split and impact figures are an informed estimate for a programme of this type — illustrative only, not official Accenture / PTTEP numbers.
Two honest views of readiness. First a competency matrix that separates what I’ve delivered on a live ERP from what I hold as concept, ready to configure under guidance. Then a real hypercare incident — diagnose it yourself and see how I’d run the fix.
Go-live is where scope meets reality. Here’s a real-shaped incident — pick where you’d look first, and see the reasoning either way.
A representative hypercare incident and resolution path; specifics vary by client. The point is the method: reproduce, isolate the layer, fix in config, retest, and leave a regression case behind.
XeerSoft isn't SAP — but four full-lifecycle ERP go-lives map cleanly onto these SAP concepts. I bring the concept understanding and the real delivery experience, and I stay precise about the line between the two.
The XeerSoft delivery in the left column isn't a claim — it's six capabilities proven with real results →
I lead with concept understanding + real full-lifecycle ERP delivery — and I never claim I've configured the Thai tax procedure on SAP.