Project 04 · STEM Portfolio Financial Tracking

Business Context & Problem

Newton Sixth Form ran a recurring STEM enrichment programme (Jan 2025 – Go-Live June 2026): students attended hands-on university lab sessions and academic competitions, billed per family. I owned the full financial lifecycle on XeerSoft: invoicing each family, tracking payment collection, investigating discrepancies, allocating cost, and reporting per-subject P&L to management.

The programme spanned seven subjects, billed per student: six hands-on lab subjects (Robotics, Biology Lab, Math Camp, Physics Lab, Chemistry Lab, Engineering Design) at ฿3,000/student, and an in-house Math Competition at ฿500/student. Each carried a different attendance and cost profile.

My Role & Accountability

Three streams running concurrently on XeerSoft Financial Accounting: (1) AR Billing Design for per-student invoicing, (2) Cost Allocation per session and subject, and (3) Management Reporting with session-level P&L.

AR Invoice Lifecycle · STEM Billing on XeerSoft

Financial Baseline · Fee Structure

📋 Per-student fees by subject · the per-subject financials below are a representative recreation, masked for confidentiality.

Subject	Fee / student	Direct cost
Six lab subjects	฿3,000	lab + transport + materials
Math Competition	฿500	staffing (in-house, no venue)

The six lab subjects (Robotics, Biology Lab, Math Camp, Physics Lab, Chemistry Lab, Engineering Design) bill ฿3,000/student; the in-house Math Competition bills ฿500/student (฿500 × 90 = ฿45,000). Fees are collected per family and reconciled before settlement, feeding the per-subject P&L below.

P&L by Subject

🔒 Representative recreation · per-subject P&L · gross profit on billed (accrual) basis · collection is a separate AR metric · figures author-provided · original XeerSoft Financial Accounting data under NDA.

Subject	Revenue	Gross Profit	Margin	Collection
Biology Lab	฿555,000	฿268,374	`48%`	`91%`
Robotics	฿534,000	฿267,020	`50%`	`94%`
Math Camp	฿390,000	฿185,302	`48%`	`100%`
Physics Lab	฿267,000	฿138,504	`52%`	`100%`
Chemistry Lab	฿264,000	฿140,094	`53%`	`98%`
Engineering Design	฿126,000	฿54,575	`43%`	`86%`
Math Competition	฿45,000	฿27,000	`60%`	`96%`

Totals (7 subjects): revenue ฿2,181,000 · gross profit ฿1,080,869 · overall margin 49.6% · collection 95.0% (฿2,071,000 collected · ฿110,000 outstanding). Gross profit is billed (accrual) basis; collection is a separate AR metric. Figures author-provided, masked for confidentiality.

Solution Design · Cost Allocation

Each session's cost splits across three categories — one variable (materials, per student), two fixed (lab fee, transport) — producing the cost side of the P&L.

🔒 Representative recreation · per-session cost model · figures illustrative · actual costs vary by session.

Cost category	Type	Basis	Per session
Lab fee	Fixed	per session (lab)	฿40,000
Materials	Variable	฿900 × 50 students	฿45,000
Transport	Fixed	per session	฿12,000
Total cost / session			฿97,000

Illustrative per-session model (Chemistry intake): revenue ฿150,000 (50 × ฿3,000) − cost ฿97,000 = gross profit ฿53,000 (~35%). Blended programme margin across all seven subjects is ~49.6% on a billed (accrual) basis (฿1.08M gross profit on ฿2.18M revenue, before staff & overhead). This is the allocation method, not a specific session.

XeerSoft Module Flow

The STEM billing & profitability process as configured in XeerSoft, module → function paths.

#	Process Step	XeerSoft Module → Function
1	Student enrolment per session	Enrolment › Register Session
2	Create per-student AR invoices	Financial Accounting › AR Invoice
3	Track collection status	Financial Accounting › AR Open Items
4	Investigate discrepancy	Financial Accounting › Payment Matching
5	Cost allocation per session	Cost Allocation › Session Order
6	Session P&L reporting	Reporting › Session P&L

Functional Spec & Build Evidence

The AR posting and reporting logic I authored in the FSD and submitted to the XeerSoft development team.

FSD-P4 · AR invoice & P&L reportspec · pseudocode

// FSD-P4-01 · Per-student AR invoice generation
FOR EACH student IN session.enrolled:
   invoice.line[1] = { 110100 Student AR    · Debit  · 3,000 THB · term NET30 }
   invoice.line[2] = { 400150 STEM Revenue  · Credit · 3,000 THB · CC branch+Academic }
   IF post(invoice) ok → COMMIT   ELSE → ROLLBACK

// FSD-P4-02 · Session P&L report
revenue      = SUM(invoices WHERE ref ~ 'STEM%')
collected    = SUM(cleared  WHERE ref ~ 'STEM%')
cost         = SUM(session_order.actual_costs)
gross_profit = collected − cost
margin %     = gross_profit / collected × 100

Live Spec Simulation

An interactive simulation that runs the FSD logic above directly in your browser: it reproduces the specified behaviour I designed, not the proprietary XeerSoft UI.

XeerSoft Cloud ERP · Financial Accounting › Session P&L Simulation SIMULATION

Session inputs · FSD-P4-01

Students enrolled · 50 Fee per student (THB) Collection rate · 95% Lab fee (fixed / session) Materials (per student) Transport (fixed / session)

Session P&L · FSD-P4-02

฿0

Gross profit · margin 0%

Revenue invoiced฿0

Collected฿0

Total cost฿0

AR position

Per-invoice posting

DR 110100 · Student AR ฿3,000
CR 400150 · STEM Revenue ฿3,000

A neutral calculator running the spec: plug in your own actuals; default cost figures are illustrative.

Delivery model · role boundary

On XeerSoft Cloud ERP I worked as Functional Consultant / Business Analyst, owning requirements, configuration, FSD authoring, UAT and defect management. The custom logic below was implemented by XeerSoft’s in-house development team against my specifications.

The pseudocode shown is the specified expected behaviour (my FSD deliverable), not vendor source code, and deliberately platform-neutral so it reads the same to a XeerSoft or generic ERP reviewer.

Solution Depth · Financial Accounting & Controlling

Per-student invoicing is the visible surface. Underneath, this was a financial accounting and management controlling implementation: seven subjects had to stay separated as profit centers, costs had to derive to the right branch cost centers, the AR sub-ledger had to reconcile to the GL control account every period, and revenue recognised on a billed (accrual) basis had to be tracked apart from cash collected. Each of those is a place the books can silently go wrong, and together they are why the build took the time it did.

⚙ The financial-control hard parts · the dimensions that made this a controlling build, not a billing form · representative of the delivered design.

Financial-control dimension	Why it is hard	How I handled it
Profit-center separation	7 subjects, one revenue stream; pool them and per-subject P&L becomes fiction	Profit center per subject, derived on every revenue posting
Cost-center derivation	Lab, materials and transport split across 3 branches (1100/1200/1300)	Substitution rules map each cost to its branch CC + dept 110 Academic
Sub-ledger ↔ GL tie-out	AR sub-ledger must equal GL 110100 control at every close, to the baht	Nightly reconciliation routine plus an exception report on any variance
Accrual vs cash	Margin is billed-basis; collection is a separate cash metric; mixing them misstates both	Revenue booked on invoice; collection tracked on a parallel AR status model
Period-end close	17 monthly closes, each blocked if the books do not tie out	Close checklist: post → reconcile → clear disputes → sign-off
Dunning & recovery	฿375K outstanding across families with partial and disputed balances	AR-aging-driven dunning recovered ฿267K, lifting collection 82.4% → 95.0%

These six dimensions are the difference between a system that prints invoices and one that produces auditable per-subject P&L. The first dev build got the invoice right and the controlling wrong, which is exactly what moved Go-Live.

Programme Scale

A financial build runs long because of volume across dimensions, not one large task. Over the engagement the programme moved roughly ฿2.18M across seven subjects and three branches, and every baht of it was invoiced, reconciled and closed.

📊 Programme scale · magnitude across the engagement · counts representative, masked from XeerSoft Financial Accounting under NDA.

Dimension	Count	Note
Per-student AR invoices	802	712 lab + 90 Math Competition, across multiple intakes
Subjects as profit centers	7	6 labs @ ฿3,000 + 1 competition @ ฿500
Branch cost centers	3	1100 / 1200 / 1300 + dept 110 Academic
GL accounts in scope	14	AR, revenue, cost, contra, dunning, tax & bank clearing
Monthly period closes	17	each gated on a clean sub-ledger ↔ GL tie-out
FSD iterations	v1 → v3	two re-specs after the GL-separation defect
UAT cycles	5	1 pre-defect + 3 regression + 1 cutover dress run
AR recovered via dunning	฿267K	of ฿375K outstanding, lifting collection to 95.0%

802 invoices × many status transitions × 17 monthly closes is the volume a per-subject P&L has to stay correct across. Counts are representative; the ฿2.18M revenue, ฿1.08M gross profit and 95.0% collection are the real programme totals.

Validation Risk · Go-Live Defect

At UAT Cycle 1 the build looked right on a single invoice and failed at the books. Every subject posted to the same AR and revenue control account with no profit-center or cost-center derivation, so two things broke at once: the AR sub-ledger stopped tying to the GL, and per-subject P&L could not be produced. In financial-control terms that is a go-live blocker, not a cosmetic bug: you cannot close a period whose sub-ledger does not reconcile. Closing it meant re-specifying the posting model and re-testing it across three regression cycles.

🔒 GL posting model · before vs after re-spec · representative recreation of the defect and the fix · account numbers illustrative.

Posting dimension	FSD v1 (defect)	FSD v3 (re-spec)
Revenue account	400150, all subjects pooled	400150 + profit center per subject (PC01–PC07)
AR control	110100, no family sub-ledger key	110100 with per-family sub-ledger, tied nightly
Cost derivation	single cost bucket, no branch	cost-center substitution → 1100/1200/1300 + dept 110
Sub-ledger ↔ GL	out of balance at close	reconciles to the baht; variance report on exception
Per-subject P&L	not derivable	7 profit centers, margin per subject
Period close	blocked	passes the close checklist

Root cause: the dev spec implemented invoicing without the controlling dimensions, so the financial picture was right in total and wrong in every breakdown management actually needed. The fix re-architected derivation at posting time: correct, but invasive enough to touch every transaction and force a full regression. That work is the +5 months between the planned and the actual Go-Live.

Validation, UAT & Defect Control

I did not sign off the build as one pass/fail. I decomposed the billing → AR → profitability scope into 10 sub-unit tests, each run as a manual test case of ~10 ordered steps validated against 5 complex conditions, with one written specific assurance per sub-unit (the exact thing the test guarantees). This is the breakdown behind the 5 UAT cycles already noted — 1 pre-defect + 3 regression + 1 cutover dress run — including the GL-separation defect that moved Go-Live.

📋 Manual test criteria · how every sub-unit was validated

Each sub-unit test is a manual procedure: log in under the correct role, drive the transaction step by step, and confirm the posting, derivation and data outcome at each gate. Every test carries 5 complex conditions — multi-subject split / discount / refund / period boundary / derivation paths — not just the happy path. A sub-unit only closes when its specific assurance holds under all five and a regression retest is clean.

Flagship worked test case · full manual procedure 10 steps · 5 conditions

UT-P4-02 Revenue account determination · per-subject GL split PASS · after DEF-P4-01

Role: Billing / Financial Accounting · tied to the GL-separation defect that moved Go-Live — FSD v1 posted every STEM subject to a single shared revenue GL, so per-subject profitability was blended and meaningless. This is the procedure that surfaced it and proved the FSD v1→v3 fix.

Manual procedure · 10 steps

Log in as Billing role; create a billing document in the XeerSoft Billing screen Billing screen for a student enrolled in multiple STEM subjects.
Confirm each enrolled subject appears as its own billing line (Robotics, Physics Lab, Math Competition …).
Verify each subject line derives its own revenue GL via account determination — not one shared GL.
Post the billing document; capture the accounting document number.
Confirm AR posts to the customer sub-ledger (student debit) for the full invoice total.
Drill the accounting view; verify the credit side splits across the per-subject revenue GLs.
Confirm the profitability segment captures subject on each line (segment populated, not blank).
Open the XeerSoft profitability report P&L report; filter to this student / intake.
Verify the per-subject revenue in the profitability report ties line-for-line to the GL postings.
Confirm the per-subject P&L is real — each subject's margin stands alone, nothing blended.

Complex conditions · 5 paths

C1Multi-subject invoice — revenue must split to the correct per-subject GLs, one line per subject, never collapsed to a shared account.
C2Discount must post to its contra account, not be netted into revenue, so gross revenue per subject stays clean.
C3Refund / credit memo must reverse to the right subject GL, not a default or shared account.
C4Period boundary — deferred vs earned revenue handled correctly when billing straddles the period close.
C5Closed-period billing must be blocked and forced to the current open period, never back-dated silently.

◆ Specific assurance

Guarantees that every subject's revenue lands in its own GL and profitability segment, so per-subject profitability is real, not blended — discounts and refunds route to the correct contra / subject account and never distort gross revenue. This is the exact failure the FSD v1→v3 re-spec fixed: it broke the core promise of the build — per-subject P&L — and is closed as DEF-P4-01.

Sub-unit test register · the full decomposition 10 components

UT-P4-01Billing document creation Billing screen · per-student invoice9 steps

One billing line per enrolled subject, mandatory fields enforced on save
Multi-subject student (lab + competition) bills on a single invoice
Zero / negative quantity rejected; unit price pulled from the price condition
Duplicate billing for the same student / intake flagged
Subject not enrolled cannot be added to the invoice

Assurance: a billing document cannot be posted without a valid per-subject line and price, and no student can be billed twice for the same intake. PASS

UT-P4-02Revenue account determination · per-subject GL split10 stepsflagship

Multi-subject invoice splits revenue to the correct per-subject GLs
Discount posts to its contra account, not netted into revenue
Refund / credit memo reverses to the right subject GL
No subject ever collapses to a shared revenue GL
Closed-period billing rejected and re-dated

Assurance: detailed above — every subject's revenue lands in its own GL and profitability segment so per-subject P&L is real. PASS · after DEF-P4-01

UT-P4-03AR posting & customer sub-ledger8 steps

Invoice total posts as a student-level AR debit in the sub-ledger
AR control account ties to the GL on every posting
Partial payment reduces the open residual, not the gross
Multiple intakes for one student stay separately open
Reversal of a billing document clears the AR line cleanly

Assurance: every invoice raises a traceable student AR balance that reconciles to the control account, and payments reduce the right open item. PASS

UT-P4-04Profitability segment derivation · segment = subject10 steps

Every billing line populates segment = subject in the profitability model
Competition subjects derive the segment, not just lab subjects
Derivation rule maps material → subject characteristic
Segment never comes through blank for any subject group
New subject added to the catalogue inherits a derivation rule

Assurance: the profitability segment is always populated with the subject, so no revenue lands in reporting unattributed. PASS · after DEF-P4-02

UT-P4-05Profitability value-field mapping · revenue / cost / contribution9 steps

Revenue, cost and discount each map to distinct value fields
Discount counted once, never double-deducted from margin
Cost flows into the contribution calculation correctly
Contribution margin = revenue − discount − cost
Value fields aggregate cleanly across an intake

Assurance: contribution margin is computed once and correctly per subject, with no value double-counted into the result. PASS · after DEF-P4-03

UT-P4-06Cost allocation · per session & subject9 steps

Lab / instructor cost allocates to the right subject segment
Per-session cost splits across enrolled students correctly
Shared cost spread by a defensible driver, not flat
Lab-partner fee lands on the correct subject only
Zero-enrolment session does not strand cost

Assurance: every session cost is attributed to the subject that incurred it, so subject margin reflects its true cost base. PASS

UT-P4-07Profitability report P&L report · per-subject P&L8 steps

Report shows one P&L column per subject, not blended
Revenue / cost / margin reconcile to the underlying GL
Filter by subject / intake / period returns correct rows
Report total ties to the GL with no rounding gap
Drill-down from total to billing line is intact

Assurance: the per-subject P&L is an auditable view that ties back to source postings, so management decisions rest on real numbers. PASS · after DEF-P4-05

UT-P4-08Period-end / settlement8 steps

Deferred revenue settles to earned at the period boundary
Costs settle to profitability reporting before the period closes
Open billing in flight does not block the close
Re-open / re-run settlement is idempotent
Post-close postings forced into the next open period

Assurance: the period closes with revenue and cost fully settled to profitability, and nothing back-dates into a closed period. PASS

UT-P4-09Dunning / collection recovery8 steps

Aging buckets driven off the open residual, not gross
Partial payments correctly reduce the aged balance
Dunning level escalates by days overdue
Disputed items held out of the dunning run
Cleared item drops out of aging immediately

Assurance: aging reflects what is actually owed after partial payment, so dunning chases the right balance — the discipline that recovered collection to 95%. PASS · after DEF-P4-04

UT-P4-10Margin reconciliation · P&L vs GL7 steps

Sum of per-subject margin reconciles to total GL result
Profitability revenue ties to the revenue GL accounts
Profitability cost ties to the cost GL accounts
No unattributed variance between the two views
Rounding / currency settings aligned across both

Assurance: the profitability view and the GL agree to the cent, so the per-subject P&L is provably complete and not a parallel set of books. PASS

Test execution timeline · UAT cycle by working day

Day 1Day 10Day 20

Billing doc & AR posting

UT-01,03

Revenue GL split (defect)

UT-02

Segment derivation (defect)

UT-04

Profitability value fields

UT-05

Cost allocation

UT-06

P&L report & period-end

UT-07,08

Dunning & margin recon

UT-09,10

Regression · all 5 fixes

retest

Cutover dress & sign-off

gate

Sub-unit testDefect foundRegression retestSign-off gate

Defect log · raised to dev → fixed → retested

ID	Sub-unit	What broke (symptom)	Sev	Root cause	Fix I specified to dev	Days	Retest
DEF-P4-01	UT-02 revenue determination	All STEM subjects posted to a single revenue GL, so per-subject P&L was blended and meaningless.	HIGH	FSD v1 account determination keyed only on billing type, not subject.	Re-spec'd account determination to derive a per-subject revenue GL (FSD v1→v3).	5	✓ PASS
DEF-P4-02	UT-04 segment derivation	Segment came through blank for competition subjects, so their revenue was unattributed.	HIGH	No derivation rule mapped material → subject characteristic for that group.	Added the derivation rule so segment = subject is always populated.	3	✓ PASS
DEF-P4-03	UT-05 value fields	Discount was double-counted in the contribution margin.	MED	Discount mapped into both revenue and its own value field.	Mapped discount to a single dedicated value field.	2	✓ PASS
DEF-P4-04	UT-09 dunning / AR	Partial payments in run-off were ignored by aging.	MED	Aging keyed on invoice gross, not open residual.	Age on the open residual after partial payment.	1	✓ PASS
DEF-P4-05	UT-07 P&L report	Report total did not tie to the GL by a small rounding gap.	LOW	Currency rounding differed between report and posting.	Aligned rounding / currency settings in the report.	1	✓ PASS

5 defects raised to the XeerSoft dev team, ~12 working days of fix-and-retest in total. The GL-separation blocker (DEF-P4-01) is the one that moved Go-Live — it broke the core promise of the build, per-subject profitability, by blending every subject into one revenue GL. All five closed with a clean regression retest. The discipline is the point: every defect has a named symptom, a root cause, a fix I specified, days-to-resolve, and a clean regression retest — nothing closed on assertion.

Configuration Parameters

XeerSoft Financial Accounting · programme & GL configparameters

// PROGRAMME · Jan 2025 – Go-Live June 2026 · LIVE
Lab subjects (×6)  : THB 3,000 / student
   Robotics · Biology Lab · Math Camp · Physics Lab · Chemistry Lab · Engineering Design
Math Competition   : THB 500 / student   (in-house · 90 students · THB 45,000)

// GL ACCOUNT MAPPING (XeerSoft Financial Accounting)
110100  Student AR        → Debit  (customer invoice)
400150  STEM Lab Revenue  → Credit (revenue posting)

Cost Centre: branch-specific (1100/1200/1300 + dept 110 Academic)

// COST CATEGORIES per session
Lab Fee (fixed)     · Materials (variable)  · Transport

// AR STATUS CODES  (post-go-live · 95% collected · ฿110K open)
OPEN     : Invoice sent, payment not received
PARTIAL  : Partial payment received, balance outstanding
CLEARED  : Full payment confirmed and reconciled
DISPUTED : Amount discrepancy under investigation

AR Lifecycle Management

Each student invoice flowed through four distinct status codes: OPEN → PARTIAL → CLEARED in the standard path, with DISPUTED as the exception branch when a bank receipt didn't match the expected amount. I personally managed the reconciliation for any DISPUTED items, cross-checking bank statements against expected receipts until every one was cleared.

AR Position (Go-Live · June 2026)

· Total Collected: ฿2.071M (95.0%), across all seven subjects

· Total Outstanding: ฿110,000 (5%), in post-go-live run-off

· Recovered ~฿267,000 of ฿375,000 outstanding AR via post-go-live dunning, raising collection 82.4% → 95.0% (margin is gross, on a billed/accrual basis, before staff & overhead)

Margin Analysis

The per-subject margin showed where the programme generated the most economic value. Math Competition led at 60% margin on a small revenue base, while Biology Lab produced the highest absolute gross profit (฿268K). Overall programme margin is 49.6%, gross and on a billed (accrual) basis — before staff and overhead. This data informed pricing and session planning.

Measured Results

The measurable outcome was a reconciled STEM financial model across 802 transactions and 7 subjects: ฿2,181,000 revenue tracked, ฿2,071,000 collected, 95.0% collection rate, ฿110,000 outstanding AR, ฿1,080,869 gross profit, and 49.6% overall margin on a billed accrual basis.

Tools & Deliverables

XeerSoft Financial Accounting Module XeerSoft AR Billing Cost Allocation Engine Power BI Dashboard Excel · Bank Reconciliation SQL · AR Aging Queries draw.io (AR Lifecycle Flow) Word (FSD)

Delivery Timeline

How the project was actually run end-to-end after the consulting work above: the timeline and where it was at risk, how I specified the build for the developers and verified it, the weekly Agile cadence, and the stakeholder network I coordinated as the single point of accountability.

⏱ Schedule stakes · why the date mattered

This was a recurring revenue cycle, not a one-off: every STEM intake billed each family ฿500–3,000. Late or inaccurate billing directly delayed cash collection, so the schedule pressure repeated every intake until the programme reached Go-Live in June 2026.

Project timeline · month-by-month

2025 · planned delivery year 2026 · slip & Go-Live

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

Discovery & As-Is

2 mo

AR + GL design (FSD v1)

FSD v1

Profit/cost-center model

PC/CC

Cost alloc + P&L spec

2 mo

Build v1 · dev handoff

build v1

UAT 1 · GL-split defect

defect

Re-spec · FSD v2–v3

re-spec

Rebuild + regression

rebuild

UAT 2–4 · sub-ledger recon

UAT ×3

Parallel run + cutover

cutover

Planned Go-Live · Dec 2025

plan

Go-Live · June 2026

go-live

Planned as a 12-month delivery (Jan–Dec 2025, the same shape as Project 02). A GL multi-account separation defect in the dev build surfaced at UAT Cycle 1: per-subject revenue and cost postings were collapsing into single control accounts, so the AR sub-ledger would not reconcile to the GL and per-subject P&L could not be trusted. Closing it took an FSD re-spec (v2–v3) plus three regression cycles, moving Go-Live to June 2026: a +5-month slip, fully recovered to 95% collection.

DeliveredRisk / slippedRecoveredGo-LivePlanned / in progress

Schedule risk & recovery

✓

GL multi-account separation defect · the +5-month driver

The dev build posted all seven subjects to single AR and revenue control accounts with no profit-center or cost-center derivation, so the AR sub-ledger did not tie to the GL and per-subject P&L was unreliable: a hard blocker for period close, and therefore for go-live. Resolved → I re-specified the posting model (FSD v2–v3) with a profit center per subject, branch cost-center substitution, and a nightly sub-ledger ↔ GL reconciliation, then ran three regression cycles to zero blocking defects before cutover.

✓

Collection recovered to 95% post-go-live

Mid-programme, collection sat around 82.4% with outstanding AR carried per family — cash tied up in OPEN/DISPUTED items. Resolved → AR aging per family plus DISPUTED reconciliation against bank receipts and post-go-live dunning recovered ~฿267,000 of ฿375,000 outstanding, raising collection 82.4% → 95.0% (฿110,000 still in run-off).

✓

Per-session margin visibility

Without per-session P&L, management couldn’t see which subjects actually earned money. Resolved → I built session-level revenue-vs-cost reporting so pricing and session planning are now driven by margin data.

Spec design → developer handoff → build verification

01Requirements & As-IsStakeholder interviews, executive sessions, current-state process mapping.

02To-Be & AcceptanceTarget process design + measurable acceptance criteria agreed up front.

03FSD AuthoringDecision tables, field-level data model, GL/workflow rules, edge cases.

04Dev HandoffSpec walkthrough with the dev team, clarify, agree Definition-of-Done.

05Build VerificationTrace the build back to the FSD: data model, posting, workflow, negatives.

06UAT → Go-Live → HypercareCycle sign-offs, defect burn-down, cutover, post-live support.

How I spec for developers

Write every rule as a decision table (input → expected output), not prose.
Specify the data model field-by-field: keys, types, validation.
Define GL posting and workflow thresholds explicitly, with examples.
Enumerate edge & negative cases up front (multi-select, zero, partial, duplicate).
Agree a Definition-of-Done before the build starts.

How I verify the build (functional, not source-code review)

Functional trace: every FSD rule reproduced in the build.
Data model check: fields, keys and validation match the spec.
Posting check: correct GL accounts, debit/credit, contra logic.
Workflow check: routing & thresholds behave per the matrix.
Negative / edge tests before happy-path sign-off (the DEF-001 lesson).
Regression after every fix: nothing closes without a retest.

Weekly Agile cadence

MON

AR aging review + DISPUTED follow-up

TUE

Bank reconciliation matching

WED

Cost allocation / session orders

THU

P&L + margin report refresh

FRI

Management update + dev sync

1× / wk

AR aging reviewconfirm

per intake

Billing & cost cycle

95.0%

Collection (post-go-live)

Stakeholder network & RACI

Chatree · sole consultant single point of accountability across enrolled families (payers) · management (P&L) · lab partner · remote XeerSoft dev team

Stakeholder	Count	Their part	RACI
You · BA + Implementation	1	Billing design, AR ops, P&L reporting	A / R
Management	few	Consume P&L; pricing decisions	C / I
Families	per intake	Billed; payment collection	I
Lab partner	1	Lab fee / cost input	C
XeerSoft dev team	remote	Built AR posting + report from FSD	R

A financial operation I ran single-handedly end-to-end — sole owner of billing, collection, reconciliation and the P&L management used to plan sessions. Went Go-Live in June 2026; AR recovered to 95% via dunning, with a clean handover to BAU.

Consultant Takeaway

The programme went Go-Live in June 2026. Post-go-live dunning recovered ~฿267,000 of ฿375,000 outstanding AR, raising collection 82.4% → 95.0% (฿110,000 still in run-off). The final per-subject P&L — gross profit ฿1,080,869 at a 49.6% overall margin on a billed (accrual) basis — is handed to management; billing, cost allocation and margin reporting run live in production, with a clean handover to BAU.