FI Tax Consultant — Scope of Work · SAP FI · GL

00 · The mandate

My current seat is the tax-control layer inside SAP Financial Accounting.

Current role Public-safe summary

In my current role on an energy-sector S/4HANA programme delivered by a global systems integrator, I contribute to the tax determination and reporting scope of Financial Accounting — principally VAT (Tax on Sales/Purchases) and Extended Withholding Tax, with the account determination and statutory reporting that sit beneath every posting. My job is to turn an agreed tax design into configuration that stands up to energy-sector compliance requirements. I don't interpret the tax law; I translate the approved requirement into testable SAP behaviour, controls and evidence.

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.

01 · Current-role scope

The seven pillars of the role.

Current role Public-safe scope model

This is the working surface of an FI tax consultant in the current programme context. Open any pillar for the public-safe activities and standard SAP transactions behind it.

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.

TAXTHFTXPOB40 FS00SPRO · Ext. WHT

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.

FB60FB70F-53 MM tax codeSD MWST

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.

PP30PND 3/53/54 RFUMSV00DRC / ACR

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.

Vendor · WHT infoCustomer · tax class. FS00 · tax category

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 in the upstream regime — 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.)

02 · How the engagement runs

How I add value in each SAP Activate phase.

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.

03 · In / out of scope

The boundary is the scope.

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.

▸ In scope — I deliver

Configure VAT tax codes (FTXP) & account determination (OB40) to the agreed design
Maintain Extended WHT types/codes and link to master data
Set tax-relevant GL master (FS00) attributes
Validate tax determination on MM, SD & FI documents
Prepare & execute tax test scripts; support UAT
Author functional specs for tax forms (WHT cert, PND, VAT layout)
Support tax data cutover & the first live filings

✕ Out of scope — hand off

Legal interpretation & rate-setting→ Client Tax SME / tax advisor
Re-designing the overall tax solution (fixed in Explore)→ FI/CO Lead + Tax SME
ABAP build of enhancements & form output→ Technical team (I write the spec)
Petroleum tax (Royalty / SRB / PITA) computation logic→ specialist provisioning; I ensure the GL exists
Corporate income-tax provisioning beyond config→ client finance / CO
Non-tax FI areas (treasury, AA policy) unless assigned→ respective FI streams

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.

Activity	Me FI Tax	FI/CO Lead	Tax SME	ABAP Tech
Tax requirement & rate decision	C	C	A/R	–
Tax code & account determination config	R	A	C	–
Tax form / report (WHT cert, PND, VAT)	R spec	A	C	R build
Tax test execution	R	A	C	I
Cutover tax data & first filing	R	A	C	I

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.

04 · Deliverables

What I put my name on.

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.

0 / 9 ready

05 · Where my work sits

Where my work lives inside SAP Financial Accounting.

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-control scope I support.

Module SAP FI — Financial Accounting

↳ my branch — Tax & Special Products — expands to:

06 · T-code playbook

The transactions I live in.

The transactions I reach for, what each one does, and where it sits in the build sequence. Filter by area.

T-code	Functional command — what it does	When
SPRO	Open the IMG — the central customizing tree. Every config path below lives here.	Config entry
OBBG	Assign the country (TH) to the tax calculation procedure TAXTH.	1 · foundation
OBYZ	Maintain the calculation procedure, condition types & account keys behind the tax codes.	2 · procedure
FTXP	Create / change tax codes and their % rate (output V-, input A-) under TAXTH.	3 · tax codes
OB40	Account determination — map each tax transaction key to the GL account it posts to.	4 · GL routing
FS00	GL account master — set the tax category & "posting without tax allowed" flags.	5 · GL master
FB60	Post a vendor (AP) invoice with input VAT + WHT — the core P2P tax test.	Test / run
FB70	Post a customer (AR) invoice with output VAT — the core O2C tax test.	Test / run
MIRO	Logistics invoice verification (MM) — input VAT on a PO-based invoice.	P2P / MM
F-53	Post an outgoing payment — where Extended WHT is realised & withheld.	Payment
FB03	Display any document — read the tax & WHT line items to verify a posting.	Verify
RFUMSV00	Advance return for tax on sales/purchases — the VAT report feeding PP30.	Month-end
FBL1N / FBL5N	Vendor / customer open & cleared line items — reconcile tax & WHT balances.	Reconcile
S_P00_07000134	Generic withholding-tax reporting — feeds the Thai WHT certificate & PND output.	Month-end
SPRO · Ext. WHT	Define WHT types (at invoice / at payment), codes (rates), and assign to the company code.	WHT config
Vendor master · WHT	Assign the WHT type + code on the vendor so postings withhold automatically.	Master data
PND 3/53/54	Withholding returns & certificates — PND 3 (individuals), 53 (companies), 54 (overseas).	Filing

Setup workflow — VAT (Tax on Sales/Purchases)

step 1OBBGAssign TH → TAXTH

step 2FTXPDefine codes & rates (7%)

step 3OB40Map tax keys → GL accounts

step 4FS00Set tax category on GL

step 5FB60 / FB70Test input & output VAT

step 6RFUMSV00Run VAT report → PP30

Setup workflow — Extended Withholding Tax

step 1SPROActivate Extended WHT

step 2WHT typeAt invoice / at payment

step 3WHT codeRate per income type

step 4Company codeAssign types & activate

step 5Vendor masterAssign WHT type + code

step 6F-53 → PNDWithhold at payment & file

The IMG path behind the config — the tree I actually navigate.

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 › SAP Reference IMG › Financial Accounting › Financial Accounting Global Settings

… Global Settings › Tax on Sales/Purchases

Basic Settings › Check Calculation ProcedureOBYZExplore

Basic Settings › Assign Country to Calculation ProcedureOBBGRealize

Basic Settings › Check & Change Settings for Tax ProcessingOBCNRealize

Calculation › Define Tax Codes for Sales & PurchasesFTXPRealize

Calculation › Assign Co. Code to Doc. Date for Tax DeterminationSPRORealize

Posting › Define Tax AccountsOB40Realize

Posting › Assign Tax Codes for Non-Taxable TransactionsOBCLRealize

… Global Settings › Withholding Tax › Extended Withholding Tax

Basic Settings › Check Withholding Tax CountriesSPROExplore

Calculation › Define W/Tax Type for Invoice PostingSPRORealize

Calculation › Define W/Tax Type for Payment PostingSPRORealize

Calculation › Define Withholding Tax CodesSPRORealize

Company Code › Assign W/Tax Types to Company CodesSPRORealize

Company Code › Activate Extended Withholding TaxSPRORealize

Postings › Define Accounts for W/Tax to be Paid OverOBWWRealize

SAP Easy Access › Accounting › Financial Accounting › General Ledger › Reporting

Tax Reports › Advance Return for Tax on Sales/PurchasesRFUMSV00Run

Withholding Tax › Generic Withholding Tax ReportingS_P00_07000134Run

Thai VAT filing (output/input VAT)PP30Run

Thai withholding returns & certificatesPND 3/53/54Run

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).

07 · Road to Go-Live

I joined during Realize. The path runs through proof, cutover and hypercare.

I entered the programme mid-stream, after the core design decisions and while the build was being hardened. This public view shows the relative SAP Activate sequence and my current-role entry point; client milestones and calendar dates are intentionally omitted.

Phase-based delivery path Relative months only · exact programme dates omitted

M−12

M−11

M−10

M−9

M−8

M−7

M−6

M−5

M−4

M−3

M−2

M−1

M0

M+1

Explore / Blueprint

Design

Realize — build & unit test

I join · Build

Integration test (SIT)

SIT

User acceptance (UAT)

UAT

Cutover / final prep

CUT

Go-Live

LIVE

Hypercare

Stabilize

Delivered (before me) Current-role entry point Planned Go-Live

ExploreThe tax design and Thai localization were settled before me — I inherit and respect it, not redesign it.

Realize · current roleRead the configured tax codes, OB40 determination and Extended WHT, then unit-test VAT and WHT behaviour against the approved design.

SIT → UATEnd-to-end P2P / O2C carrying tax, period-end VAT and WHT runs, then business sign-off.

CutoverMigrate open items with tax, opening balances and WHT carry-forward; move transports; dry-run.

Go-Live → HypercareValidate the first live tax postings, then carry the first month-end PP30 and PND filing before handover.

PUBLIC-SAFE SUMMARY · Relative sequence only. Exact dates, milestones and the client delivery schedule are intentionally omitted.

08 · Petroleum tax engine

The taxes an upstream operator meets — and how SAP posts them.

Two layers meet in an upstream operator: 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.

Base: Sale / service value invoiced to the customer.
SAP mechanism: Output tax code (e.g. O7) in FTXP under TAXTH; routed by OB40 to the Output VAT GL.
Posting / form: Attaches on FB70 (AR); reported on PP30.
Note: Output − Input = VAT payable for the month.

Base: Purchase / service value billed by the vendor.
SAP mechanism: Input tax code (e.g. A7) in FTXP; OB40 → Input VAT GL.
Posting / form: Attaches on FB60 / MIRO; reclaimed on PP30.
Note: Only claimable with a valid full tax invoice (Revenue Code §86/4).

Base: Service fee paid to a company (PND 53) before VAT.
SAP mechanism: Extended WHT type (at payment) + code (3%) on the vendor master.
Posting / form: Withheld on F-53; certificate + PND 53.
Note: I pay the vendor the net and remit the 3% to the Revenue Department.

Base: Professional / consulting fee to a company.
SAP mechanism: Extended WHT code 3% on the vendor; distinct income type for the PND line.
Posting / form: F-53 → PND 53.
Note: Individual payees may sit on a different rate / PND 3.

Base: Rent paid for property / equipment hire.
SAP mechanism: Extended WHT code 5% on the vendor master.
Posting / form: F-53 → PND 53.
Note: Rental ≠ service — different rate & income type; watch mis-coding.

Base: Domestic transport service fee.
SAP mechanism: Extended WHT code 1%.
Posting / form: F-53 → PND 53.
Note: Pure transport only; bundled logistics may be 3% services.

Base: Advertising fee.
SAP mechanism: Extended WHT code 2%.
Posting / form: F-53 → PND 53.
Note: Rare for upstream E&P but configured for completeness.

Base: Interest paid (e.g. on borrowings) to a company.
SAP mechanism: Extended WHT code 1%.
Posting / form: F-53 → PND 53.
Note: Cross-border interest may shift to PND 54 + a DTA rate.

Base: Service paid to an overseas supplier but used in Thailand (e.g. offshore technical / rig services).
SAP mechanism: Self-assessment tax code that books output & input VAT together; filed on PP36.
Posting / form: Remit output VAT via PP36; reclaim as input on PP30 next period.
Note: Common & high-value for upstream E&P — a key thing to get right.

Rate & base: 5–15% sliding scale on gross revenue by output; under a PSC fixed 10% of gross.
Deductible?: Yes — expensed, lowering the PITA base.
SAP mechanism: A cost / royalty GL provision & posting — not an FTXP tax code. Collected by DMF.
Note: Petroleum levy — period computation, not transactional VAT/WHT.

Rate: Windfall tax 0–75% (ceiling 75% of petroleum profit).
Applies to: Thailand III concessions only — a PSC has no SRB; paid only in profit years.
Deductible?: Yes — deductible (expensed).
SAP mechanism: Specialised periodic computation provisioned in GL — not a standard tax code.

Rate: Concession = 50% of net profit; PSC = 20%. Thailand's major Gulf gas blocks moved to the PSC regime in 2019. Separate Act from normal CIT.
Interest: Not deductible. Loss carry-forward 10 accounting periods; no carry-back.
SAP mechanism: An income-tax provision on net profit — period-end posting, may use USD functional currency.
Note: Exports priced at the higher of realised or "tax reference" price.

Applies to: Downstream refined products (diesel, gasoline) at refineries, petrochemical plants and fuel-retail sites.
For an upstream operator?: No. Upstream E&P sits under PITA. Do not conflate excise with upstream tax.
SAP mechanism: Not in this project's scope — listed only to mark the boundary clearly.

Try it — the SAP FI mechanism

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.

Invoice base amount (THB)

Withholding tax (PND 53)

Add input VAT 7% (Tax on Purchases)

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 statutory figures and post as provisions, not transactional codes.

Beyond the document — the petroleum layer

VAT & WHT post on every invoice. But an upstream operator'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 upstream profit.

▲ Upstream E&P — tax on PROFIT

Revenue — gas / crude sold
− Operating cost
− Capital allowance (depreciation)
− Royalty (5–15% gross · PSC 10%) deductible
− SRB (Thailand III windfall) deductible
= Taxable petroleum profit
− PITA (PSC 20% / concession 50%)
= Company net profit

▼ Downstream · refining · petrochem · retail — tax on the PRODUCT

Refining & marketing
Product sale — diesel, gasoline, jet, LPG
+ Excise (฿/litre × volume) indirect
+ VAT 7%
= Consumer pump price

Excise is charged per litre and built into the price — the consumer bears it. It never touches upstream profit. Downstream firms also pay normal CIT 20%.

Petroleum income tax — run the upstream flow

The real upstream computation: Royalty and SRB are deducted first, then PITA is charged on the remaining petroleum profit. Government take = Royalty + SRB + PITA. (M฿ = million baht.)

Revenue — gas / crude sold (M฿)

Operating cost (M฿)

Capital allowance / depreciation (M฿)

Fiscal regime

Royalty rate (% of gross)

Government take

0

Royalty + SRB + PITA

Company keeps

0

net profit after tax

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. Gulf of Thailand gas blocks run under PSCs (PITA 20%). In SAP these post as period-end GL provisions, never transactional tax codes.

09 · Legal watch-list

The Thai tax law I design against.

The statutes and rules that can become configuration decisions and test cases for an upstream energy operator. Open each for what it governs and the SAP implication a consultant validates.

Governs: Petroleum income tax (20% PSC / 50% concession); interest non-deductible; 10-year loss carry-forward; USD functional currency; export "tax reference" price.
SAP watch: Model as a period-end GL provision & currency config — never as a transactional FTXP code.

Governs: Royalty (5–15%, PSC 10%) to DMF; SRB (0–75%, Thailand III only); concession vs PSC regimes.
SAP watch: GL provisioning + DMF remittance postings; ensure deductibility flags feed the PITA base correctly.

Governs: 7% VAT, the tax point (time of supply), and the mandatory full tax-invoice fields (§86/4).
SAP watch: FTXP rate, output/input determination, tax-invoice form layout & number ranges.

Governs: Withholding on domestic & cross-border payments; certificate issuance; PND 3 / 53 / 54.
SAP watch: Extended WHT types/codes per income type; certificate & PND output programs.

Governs: The statutory 10% VAT reduced to 7%, renewed periodically by Royal Decree.
SAP watch: Maintain the tax-code rate with validity dates; plan for a rate-change cutover if the decree lapses.

Governs: Self-assessed VAT on services paid to overseas suppliers but used in Thailand.
SAP watch: Dedicated self-assessment tax code + PP36 reporting — critical for E&P importing rig / technical services.

Governs: PP30 (VAT) by the 15th of the next month (23rd via e-filing); PND by the 7th (extended for e-WHT).
SAP watch: Posting periods, the tax reporting date, and report-run timing must line up with these dates.

Governs: Revenue Department electronic tax invoice / receipt and e-WHT submission.
SAP watch: DRC / integration, digital signature, document numbering & XML output formats.

Governs: Arm's-length pricing for related parties inside the group and the petroleum export reference price.
SAP watch: Intercompany pricing conditions & documentation extracts to support the TP Disclosure Form.

Governs: Reduced / zero WHT on cross-border payments to treaty-country vendors holding a residence certificate.
SAP watch: A WHT code per treaty rate (PND 54) and a control to require the residence certificate before applying it.

Reference only — not legal or tax advice. Always confirm with the client Tax SME / advisor and current Revenue Department / DMF guidance before configuration.

10 · The platform underneath

I build on S/4HANA, not ECC.

The programme runs on 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.

ECCS/4HANA

Universal Journal

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.

ECCS/4HANA

Business Partner

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.

ECCS/4HANA

New Asset Accounting

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.

ECCS/4HANA

Fiori & embedded analytics

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.

Why it matters for me — the tax I configure lands in one real-time journal, on one Business Partner, surfaced through Fiori — so a VAT or WHT figure is traceable end to end and defensible in an audit. Central Finance / Group Reporting then rolls it up across group entities.

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.

11 · The programme & the impact

A complex energy-sector S/4HANA transformation — and the FI tax scope within it.

Current role Public-safe summary

This is not a one-consultant build. On an energy-sector S/4HANA programme delivered by a global systems integrator, FI tax sits inside a cross-functional model spanning business, functional, engineering, data, testing and change teams. This view shows the interfaces and intended controls without disclosing client identity, staffing, locations or programme dates.

E2E

cross-functional S/4HANA delivery

FI/CO

the host workstream for the role

TAX

functional specialization and control scope

TRACE

requirement → posting → evidence

How the team is shaped

Business-facing functional layer client interface

Functional consultants across FI/CO and the integrated process streams
Tax SMEs and localization leads for statutory requirements and UAT
Business analysis, programme governance and organisational change

Engineering & platform layer build and operate

ABAP development and form/output build against approved functional specifications
Basis, Security/GRC, data migration and integration specialists
Independent test, release, hypercare and application-support capabilities

My current seat — within the FI/CO workstream, I contribute to the tax scope: VAT, Extended WHT and petroleum-levy GL touchpoints. The role connects the approved tax requirement to functional design, build clarification, test evidence and handover across the delivery team.

The impact it's built to unlock projected

1 sourceA single, real-time book of financial truth across group entities — replacing reconciled silos and offline spreadsheets.

Faster closeA shorter, more automated period-end — finance reporting in hours, not days of manual consolidation.

Audit-ready taxVAT & WHT determined and posted automatically on every document, with statutory output (PP30 / PND) generated from the system — lower compliance risk, fewer manual errors.

Petroleum-fitUSD functional currency, "tax reference" export pricing and Royalty / SRB / PITA provisioning handled in-system instead of in spreadsheets.

My piece of that number — if the tax engine is right, every invoice posts the correct VAT and WHT, and every month's PP30 and PND filing comes straight out of SAP: on time, traceable and defensible in an audit. That compliance risk is what I'm here to retire.

PUBLIC-SAFE SUMMARY · No client identity, staffing level, delivery-location split or programme schedule is disclosed. Outcomes above are intended design objectives, not official client forecasts.

12 · Proving it works

Configuring it is the easy half. Proving it is the job.

Anyone can set a rate in FTXP. What a client is actually buying is the evidence that every document, in every scenario, across every integration, posts the tax correctly — and the discipline to tell the difference between a defect and a design decision when it does not.

The ladder each object climbs

Phase	Who runs it	What it proves	What I produce
UT	Developer	The code does what the technical design says.	Nothing — I review the evidence, I don't produce it.
FUT functional unit test	Me	The object meets the functional design — one object at a time, in isolation.	Numbered test cases against each FD requirement, with a posted document and a table trace per case.
SIT system integration test	Cross-workstream team	End-to-end business scenarios hold together across MM, SD, FI and the interfaces.	My steps in the E2E script, with evidence captured at each tax-relevant point.
UAT	Business users	The business accepts it.	Support, triage and fast turnaround on anything tax-shaped.
Regression	Team	The fixes did not break anything that already worked.	A re-run set for the tax scenarios most likely to be disturbed.

◆ The distinction that defines the role

FUT proves the object. SIT proves the business process. An object can pass FUT perfectly and still fail SIT, because SIT is where the tax code arrives from a purchase order rather than from my hand, and where the document that reaches FI was created by someone else's transaction. Most of the genuinely interesting tax defects live in that gap.

How I work a defect

1 · Evidence before action

Table trace (SE16N), the document (FB03 in the general ledger view), then the configuration. Only then do I raise anything. A ticket without a document number is an opinion.

2 · Isolate with a pair

Find two documents differing in exactly one variable — one tax code, one currency, one profit centre. The difference between them is the cause. One document is an anecdote; a pair is an argument.

3 · Three layers, in order

Does the master data exist? Is the configuration right for this company code? What was actually posted? Working them out of order is the most reliable way to lose a day.

One defect, one document, one discriminating argument. A ticket that says "WHT is wrong" gets bounced; a ticket that says "document 19…12 withheld on the gross 107,000 instead of the net 100,000, while document 19…13 with the same vendor and no VAT withheld correctly, so the base type on the WHT type is including tax" gets fixed.

The line that protects a project "Never raise as a defect what the signed design says is intended." Half of what looks wrong in test is a locked design decision somebody has forgotten. Checking the design first costs five minutes; raising it costs a developer a day and costs you credibility.

Root causes are categorised for a reason — data, configuration, coding error, environment, design gap. Being able to say which one you are looking at, early and confidently, is most of what separates a consultant from a tester. The mechanics of actually reading the document are on the FI Document Simulator.

13 · Ready on day one

What I can do now — and how I behave when it breaks.

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.

Tap a competency to see the evidence behind the rating.

Hypercare, played out. Diagnose it yourself.

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.

P1 · Go-live

08:40, go-live day. Branch 2000’s sales invoices are posting the 7% output VAT to the wrong GL account. The VAT amount is correct; only the target account is off. The first PP30 filing is three weeks out.

Your first move — where do you look?

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.

14 · Where my depth comes from

Where my depth actually comes from.

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.

My XeerSoft delivery	Maps to SAP concept
POS-to-accounting auto posting	Automatic account determination + tax posting (OB40)
GL mapping	Tax GL configuration
AR open-item & dunning	FI-AR open items + output VAT
Multi-branch consolidation	Company-code structure

The XeerSoft delivery in the left column isn't a claim — it's six capabilities proven with real results →

Say it this way "XeerSoft isn't SAP — but I've delivered the same concepts end-to-end on a real ERP: automatic tax posting, GL mapping, AR open items, multi-branch structure. I bring concept understanding plus full-lifecycle delivery experience — configuration, master data, UAT and go-live. I haven't configured the Thai tax procedure on SAP, and I won't claim I have; my scope here is to understand what's configured, prove it in test, and support cutover and run."

The one rule

I lead with concept understanding + real full-lifecycle ERP delivery — and I never claim I've configured the Thai tax procedure on SAP.