Project 02 · Strategic Pricing & AR Configuration

Business Context & Problem

Tuition fee pricing was managed ad-hoc per family by the school owner. No structured pricing model existed in the system: discounts varied by sibling enrolment, group/cohort intake, and referral but were only held in the owner's knowledge.

Three pain points

· Pricing decisions took 480 minutes (8 hours) on average: each new family required the owner to mentally recalculate from scratch

· AR collection at 78%: manual tracking with no systematic overdue follow-up

· Knowledge concentrated in one person: no way to scale or delegate pricing decisions

⏲ How the 480 → 15 min was measured

Before

~480 min

The owner re-derived every family quote from scratch, holding all the discount logic in her head — roughly 8 hours of senior time per pricing case.

→

After

~15 min

The system applies the 3-variable model and generates the quote and posting; admin staff run it without involving the owner.

Basis: elapsed senior-decision time per new pricing case, before vs after Go-Live. Figures are approximate (owner-reported): the point is the order-of-magnitude shift from manual derivation to system-generated pricing, not a stopwatch measurement.

My Role & Accountability

The hardest part wasn't building the system: it was extracting tacit pricing knowledge from the owner's head. I volunteered to attend weekly Executive Sessions every Sunday for 12 months (4 hours each, 48 sessions total) as the sole consultant to do so consistently.

In each session, I observed live 1-on-1 family advisory conversations, noted the variables that influenced the owner's pricing decisions, and progressively built a structured model. After 6 months of observation, I had identified three core pricing variables that explained nearly every historical decision.

The pricing conditions identified

1. Family / sibling (SIBLING): a sibling already enrolled → −฿50,000

2. Group / cohort (GROUP): three enrolling together → −฿75,000 on the third

3. Referral (REFERRAL): referred by an existing family → −฿15,000 to −฿30,000

Solution Design · Strategic Pricing & AR

The discovery distilled into a system blueprint: how a pricing-and-AR platform would be structured to operationalize the conditions above. Presented as design; prospect data anonymized (e.g. Prospect-001).

🔒 System design blueprint — conceptual architecture and reference stack, not a deployed production system. Pricing figures per author; pricing rules do not stack (best single discount applies, [TODO: Chatree to confirm]).

A · 3-tier architecture

Tier 1Presentation

Admin Consolepricing & AR operations

Parent Portalquotes · invoices · payments

⇅

Tier 2Application

Pricing Enginerate card + pricing rules

Billing Rulesinvoice · terms · dunning

Enrollment Workflowprospect → enrolled

⇅

Tier 3Data

Customerprospects · families

Catalogprogrammes · tracks

Pricingprice list · pricing rules

ARinvoices · payments

B · Module map

CRM / Customer Master

Prospect → Lead → Enrolled, holding the discovery data captured across the executive sessions.

ProspectFamilyStage

Program Catalog

Three tracks, each a sellable programme on the rate card.

MedicineCom-AIBusiness

Pricing Engine

Rate card (base ฿350,000) plus discount rules SIBLING / GROUP / REFERRAL, applied as the best single discount.

BASE tuitionSIBLING / GROUP / REFERRAL

Billing & AR

Invoice, payment terms, receivable, and the 3-level AR aging / dunning.

InvoicePaymentAging

Analytics

Segmentation, gross-vs-net revenue, and the prospect → enrolled conversion funnel.

SegmentsGross/NetFunnel

C · Data model · ER diagram

Entity-relationship · pricing & AR schema

D · Pricing engine flow

Base tuition฿350,000

→

Conditionnone

→

Net price฿350,000

→

Invoice → ARopen item

Single enrolment: full base tuition, no discount.

E · Reference architecture

🔒 Reference architecture (conceptual)

A design proposal mapping the tiers to a candidate stack — not a deployed system. Stack is illustrative and to be confirmed.

PresentationReact

ApplicationNode · NestJS

DataPostgreSQL

PricingRules engine

AR Dunning Workflow · Designed for XeerSoft

XeerSoft Module Flow

Pricing and AR process as configured in XeerSoft: module → function paths, no transaction codes.

#	Process Step	XeerSoft Module → Function
1	Define multi-tier pricing rule types	Pricing › Pricing Rule Setup
2	Enter discount records per tier	Pricing › Price / Discount List
3	Pricing → Accounting integration	Financial Accounting › Revenue Account Mapping
4	Monitor AR open items per family	Financial Accounting › AR Open Items
5	3-level dunning run	Financial Accounting › Overdue / Dunning
6	Clear customer payment	Financial Accounting › Payment Matching

Functional Spec & Build Evidence

The pricing and AR business rules I authored in the FSD and submitted to the XeerSoft development team.

FSD-P2 · pricing & AR rulesspec · pseudocode

// FSD-P2-01 · Pricing rules (best single discount, no stacking — [TODO: Chatree to confirm])
ON enrolment.price:
   base = 350,000                       // BASE tuition / yr
   SIBLING sibling enrolled  → −50,000
   GROUP cohort of 3      → −75,000     // on the 3rd enrolment
   REFERRAL referral         → −15,000 … −30,000
   discount = best_applicable           // pricing rules do not stack
   net = base − discount                // → Invoice + AR · GL 400300 contra

// FSD-P2-02 · AR aging → dunning trigger
FOR EACH open_item:
   overdue = today − due_date
   0      → CURRENT
   1–15   → WARN        // Dunning L1
   16–30  → FORMAL      // Dunning L2
   >30    → ESCALATE    // Dunning L3

AR Aging & Dunning Trigger

The aging analysis the dunning run reads (FSD-P2-02): every open item is bucketed by days overdue, and each bucket fires the matching dunning level. Driving overdue items down moved average days overdue 42 → 12 and collection 78% → 96%.

🔒 Representative recreation · aging buckets per FSD-P2-02 · item counts and amounts illustrative · the 42 → 12 days and 78% → 96% aggregates are the real results.

Aging bucket	Status	Dunning action	Open items	Amount (illus.)
0 days	CURRENT	Within terms — no action	—	—
1–15	WARN · L1	Day+15 soft reminder (no penalty)	12	฿186,000
16–30	FORMAL · L2	Day+30 formal notice + academic warning	5	฿98,000
> 30	ESCALATE · L3	Day+45 director escalation + enrolment hold	2	฿44,000

Real outcomes: average days overdue 42 → 12 · collection rate 78% → 96%. Bucket counts and amounts are illustrative; the bucket-to-dunning mapping is the configured logic.

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 · Pricing & Financial Accounting › Spec Simulation SIMULATION

Applicable pricing rules

Sibling already enrolled SIBLING −฿50,000 3rd of a group of 3 GROUP −฿75,000 Referred by a family REFERRAL −฿15–30k Referral amount

Net price · best single discount

฿350,000

AR / Revenue posting

Pricing rules do not stack — the best single discount applies (assumption · [TODO: Chatree to confirm]). GROUP −฿75,000 is the adjustment on the 3rd enrolment of a group of 3.

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.

Pricing Configuration

The three variables were mapped into structured pricing conditions within XeerSoft. Each variable has scale-based discount logic with clear thresholds.

XeerSoft · pricing rule configparameters

// PRICING CONDITION TYPES (XeerSoft Pricing Module)
BASE Base Tuition     = ฿350,000 / year
SIBLING Family / Sibling = −฿50,000         ← sibling already enrolled
GROUP Group / Cohort   = −฿75,000         ← 3 together, on the 3rd
REFERRAL Referral         = −฿15,000 … −฿30,000
   // pricing rules do not stack — best single discount applies [TODO: Chatree to confirm]

// PAYMENT TERMS
NT30   Net 30 days
INST2  50% + 50% (month 1 + 3)
INST4  25% × 4 instalments

// GL ACCOUNT MAPPING
ZSD → GL 400100  Tuition Fee Revenue
ERS → GL 400300  Family Discount (contra-revenue, NEGATIVE)
    → GL 110100  Student AR (Customer open item)

Pricing Pricing Rule Records

The pricing model as pricing rule records: a base tuition plus three discount rules. Pricing rules do not stack — the best single discount applies (assumption, [TODO: Chatree to confirm]).

🔒 Representative recreation · pricing rule records per author · original XeerSoft master data under NDA · referral shown as a range.

Code	Condition	Logic	Value	Posts to
BASE	Base tuition	Rate card · per year	฿350,000	CR 400100 revenue
SIBLING	Family / sibling	Sibling already enrolled	−฿50,000	GL 400300 contra-rev
GROUP	Group / cohort	3 enrolling together	−฿75,000 on the 3rd	GL 400300 contra-rev
REFERRAL	Referral	Referred by a family	−฿15,000 … −฿30,000	GL 400300 contra-rev

Posting per priced contract: DR 110100 Student AR · CR 400100 Tuition Revenue · DR 400300 Discount (contra, negative). Pricing rules do not stack; best single discount applies [TODO: Chatree to confirm]. Earlier commitment / academic flags retired (no supporting data). Payment terms: NT30 · INST2 (50/50) · INST4 (25×4).

Validation Outcome

Conducted 4 UAT sessions in May 2024 across multiple family profiles and edge cases: verified system behaviour against business rules for every scenario from single-child standard to 4-child advanced track with mixed payment terms.

Go-live June 2024: executives now drive all pricing decisions from system data, replacing ad-hoc per-family negotiation entirely. The shift from intuition to system also enabled delegation for the first time: admin staff can now generate accurate quotes without involving the owner.

Validation, UAT & Defect Control

I did not sign off the build as one pass/fail. I decomposed the pricing + receivables 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 4 UAT sessions in May 2024 noted above — the part that is easy to claim and hard to show.

📋 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 pricing, posting and due-date outcome at each gate. Every test carries 5 complex conditions — discount-tier / surcharge-variance / override-priority / mixed-terms / period-control 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-P2-01 Pricing rule set · pricing rule resolution (4-child advanced-track family) PASS · cycle 2 (after fix)

Role: Billing / AR · tied to the live UAT blocker above — a 4-child family where the sibling discount was not applied to the 3rd and 4th child. This is the procedure that surfaced it: resolving the correct net price per child through the pricing rule resolution end-to-end into AR.

Manual procedure · 10 steps

Log in as Billing role; open the family (customer) master for a 4-child advanced-track household with mixed payment terms.
Confirm the pricing rule set is assigned to the tuition-billing context and document profile for tuition billing.
Trace the rule priority — from most specific (per child / sibling rank) down to the base rate-card record.
Verify the pricing rule records Rate card setup exist for base tuition, sibling tiers and the advanced-track surcharge.
Create the billing document; let the procedure resolve one pricing rule record per child via the rule priority.
Confirm the base tuition rule is picked for every child before discounts apply.
Confirm the sibling-discount tier steps up correctly for the 1st → 4th child (not capped at the 2nd).
Confirm the advanced-track surcharge stacks on top of the discounted base in the right sequence.
Read the resulting net price per child; reconcile the four line totals to the priced contract.
Post to accounting; confirm each line bills to AR AR open-items view with the correct net amount and due date per that child's payment term.

Complex conditions · 5 paths

C1Sibling-discount tiers must apply to the 3rd & 4th child, not just the 2nd — the silent stopper this test was built to catch.
C2Advanced-track surcharge must stack correctly with the discount, in the right sequence, never net negative.
C3Scholarship / override condition must take priority via an exclusion group, suppressing the standard discount.
C4Mixed payment terms across siblings must each post to the right due date, not a single household term.
C5Back-dated billing into a closed period must be rejected and forced to the current open period.

◆ Specific assurance

Guarantees the rule priority resolves the correct pricing rule record per child, that discounts, surcharges and overrides combine in the right priority (override > surcharge > tiered discount > base), and that every line bills to AR with the correct net amount and due date. A sibling tier that fails to step up past the 2nd child is caught at pricing, not after invoicing — the exact failure mode caught in UAT cycle 1 and closed as DEF-P2-01.

Sub-unit test register · the full decomposition 10 components

UT-P2-01Pricing rule set · pricing rule resolution10 stepsflagship

Rule priority resolves the right record per child
Sibling tier steps up to the 3rd & 4th child
Advanced-track surcharge stacks in correct sequence
Override / scholarship wins via exclusion group
Mixed terms post each line to the right due date

Assurance: detailed above — the pricing rule resolution derives the correct net price per child and every line bills to AR with the right amount and due date. PASS · after DEF-P2-01

UT-P2-02Pricing rule records Rate card setup · tiered sibling / volume discount9 steps

Validity dates and scale bands maintained correctly
1st → 4th child each pick the right discount tier
Cohort (3 enrolling together) tier applied to the 3rd
Expired record falls back to the base rate card
Overlapping records resolve by access-sequence priority

Assurance: a maintained discount record always resolves to one unambiguous tier per child, and an expired band never silently zeroes the price. PASS

UT-P2-03Billing document · invoice from pricing9 steps

Billing doc carries the resolved net price intact
One invoice per family with a line per child
Discount / surcharge rules printed transparently
Post to accounting generates the AR posting
Cancellation reverses the invoice and the AR line

Assurance: the invoice is a faithful render of the pricing result — no figure changes between procedure and printed document, and a cancellation fully reverses to AR. PASS

UT-P2-04AR posting & customer (family) master8 steps

Family master links all children under one AR account
Reconciliation GL 110100 hit on every billing
Payment-term default inherited but overridable per child
Duplicate family record detection on create
Open-item management keeps each invoice clearable

Assurance: every billed line lands as an open item on the correct family AR account against the right reconciliation GL, clearable independently. PASS

UT-P2-05Credit control · credit-limit check FD329 steps

Limit enforced at billing for a family at exposure
Open credit memos reduce exposure, not just debits
Blocked family routes to a release worklist
Limit increase re-evaluates blocked documents
Partial payment frees credit on next check

Assurance: the credit check reflects true net exposure including open credit memos, so a family is neither wrongly blocked nor over-extended. PASS · after DEF-P2-03

UT-P2-06Dunning procedure F150 · multi-level10 steps

Dunning levels advance only on truly overdue items
Same-day-cleared invoice excluded from the run
Grace days respected before level 1 is reached
Per-level letter text and charges correct
Dunning history written back to the AR item

Assurance: no family is dunned for an invoice already paid, and an item only advances a dunning level when it is genuinely overdue at run time. PASS · after DEF-P2-02

UT-P2-07AR aging AR open-items view8 steps

Buckets age on the net due date, not document date
Mixed-term siblings age into the right buckets
Partial payments reduce the aged open balance
Credit memos net against the right age band
Aging totals reconcile to the AR sub-ledger

Assurance: the aging report measures lateness from when money was actually due, so overdue buckets are an honest basis for collections. PASS · after DEF-P2-04

UT-P2-08Payment terms · split & partial payments9 steps

Instalment plan (50/50, 25×4) generates correct due dates
Partial payment clears proportionally, leaves residual open
≤฿1 rounding residual auto-written-off, not stuck
Early payment within terms recorded correctly
Over-payment posts as a credit on account

Assurance: instalment and partial payments clear to the cent and a trivial rounding residual never blocks an otherwise fully-paid invoice. PASS · after DEF-P2-05

UT-P2-09Mixed payment terms across siblings8 steps

Each child can carry a different term on one family AR
NT30 / INST2 / INST4 lines coexist on one account
Due dates derive per line, not per household
Dunning and aging respect the per-line term
A term change on one child leaves siblings untouched

Assurance: siblings on different payment terms are billed and chased independently, so one child's plan never distorts another's due date. PASS

UT-P2-10Statement / AR report reconciliation7 steps

Family statement lists every open and cleared item
Statement balance ties to the AR sub-ledger
Aging, dunning level and term shown per line
Report totals reconcile to the GL reconciliation account
Authorisation: staff see only their assigned families

Assurance: the statement is an audit trail — every line is attributable and the figures reconcile back to the AR sub-ledger and the GL. PASS

Test execution timeline · UAT cycle by working day

Day 1Day 8Day 16

Pricing + pricing rule records (defect)

UT-01–02

Billing doc & AR posting

UT-03–04

Credit-limit check

UT-05

Dunning multi-level

UT-06

AR aging

UT-07

Payment terms & mixed-term siblings

UT-08–09

Statement / AR reconciliation

UT-10

Regression · all 5 fixes

retest

Sign-off & Go-Live readiness

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-P2-01	UT-01 pricing	Sibling discount not applied to the 3rd and 4th child — only the 2nd child got a tier.	HIGH	Rule priority picked the wrong (2-child) condition tier and never stepped up beyond it.	Re-ordered the rule priority and added a dedicated 3rd / 4th-child tier key so each sibling resolves its own record.	3	✓ PASS
DEF-P2-02	UT-06 dunning	A same-day-cleared invoice still advanced to dunning level 2.	HIGH	The dunning run read open status before the payment posting committed.	Re-check open status at run time and exclude same-day clearings from the selection.	2	✓ PASS
DEF-P2-03	UT-05 credit check	Credit-limit check used gross exposure, ignoring open credit memos.	MED	Exposure calculation summed debits only.	Include open credit memos in the exposure calculation so the limit reflects net position.	2	✓ PASS
DEF-P2-04	UT-07 AR aging	Invoices bucketed by document date, not due date.	MED	Aging keyed on the posting date.	Age on the net due date instead, so buckets reflect actual lateness.	1	✓ PASS
DEF-P2-05	UT-08 partial pay	A ≤฿1 rounding residual blocked clearing of an otherwise fully-paid invoice.	LOW	No tolerance on the residual amount.	Added an auto-write-off tolerance for a ≤฿1 residual so trivial differences clear.	1	✓ PASS

5 defects raised to the XeerSoft dev team across the UAT window, ~9 working days of fix-and-retest in total. Two were go-live blockers (discount tier not stepping up, dunning a cleared invoice); all five closed with a clean regression retest before sign-off. The discipline is the point: every defect has a named symptom, a root cause, a fix I specified, and a retest result — nothing closed on assertion.

Measured Results

The outcome was a pricing and receivables model that turned tacit owner judgment into repeatable system logic. Pricing decision time moved from 480 min to 15 min, average days overdue from 42 days to 12 days, and AR collection rate from 78% to 96%. Those are the same audited results shown in the executive KPI cards and Power BI exhibit above.

Tools & Deliverables

XeerSoft Pricing Module XeerSoft AR Module XeerSoft Dunning FSD Authoring (Word) Power BI Jira · UAT Defect Log draw.io (Process Flow) SQL (AR Aging Queries) Excel · Pivot Tables

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

Every month without a pricing system meant the owner re-deriving each family quote from scratch and inconsistent discounts leaking margin. The hardest schedule risk was the open-ended discovery of tacit knowledge (pricing logic that lived only in the owner’s head) which could have run indefinitely.

Project timeline · month-by-month

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

Discovery (48 exec sessions)

6 mo

Pattern synthesis → 3 vars

2 mo

FSD authoring

2 mo

Dev build + reviews

2 mo

UAT (4 sessions)

UAT

Go-Live

LIVE

DeliveredRisk / slippedRecoveredGo-LivePlanned / in progress

Schedule risk & recovery

✓

Open-ended discovery: risk of never converging

Six months of weekly sessions could have continued forever without ever producing a buildable spec; tacit knowledge resists deadlines. Resolved → I set a hard synthesis checkpoint at month 6, forced convergence to 3 measurable pricing variables, and only then opened the build phase, turning an infinite discovery into a finite spec.

⚠

Single-owner dependency

All pricing authority sat with one person; that is both the source of the tacit knowledge and a delivery bottleneck. Resolved → Post Go-Live, admin staff can now generate accurate quotes from the system without the owner: the dependency was designed out.

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

SUN

Executive pricing session (4 hr)

MON

Synthesise notes → variables

WED

FSD / build review with dev

THU

Test pricing scenarios

FRI

Log + sign-off

Weekly executive sessions

UAT sessions (May 2024)

1× / wk

Dev build syncconfirm

Stakeholder network & RACI

Chatree · sole consultant single point of accountability across school owner / executive · admin staff · ~enrolled families · remote XeerSoft dev team

Stakeholder	Count	Their part	RACI
You · BA/Consultant	1	Discovery, FSD, config, UAT lead	A / R
School owner	1	Pricing decision authority; sponsor	A / C
Admin staff	several	Generate quotes post Go-Live	I / R
Families	many	Subjects of the pricing & AR	I
XeerSoft dev team	remote	Built pricing/dunning logic from FSD	R

A 12-month project sustained by one consultant volunteering for 48 Sunday sessions: I was the only person translating the owner’s tacit pricing logic into a system the whole admin team could run.

Consultant Takeaway

The biggest learning was that BA work isn't just documenting what people say: it's pattern recognition over time. The owner couldn't have told me the three pricing variables on day one because she didn't consciously know them. The model emerged from observing 48 sessions and looking for the invariants underneath case-by-case decisions.

Strategic Pricing& AR Configuration

Business Context & Problem

My Role & Accountability

Solution Design · Strategic Pricing & AR

CRM / Customer Master

Program Catalog

Pricing Engine

Billing & AR

Analytics

XeerSoft Module Flow

Functional Spec & Build Evidence

AR Aging & Dunning Trigger

Live Spec Simulation

Pricing Configuration

Pricing Pricing Rule Records

Validation Outcome

Validation, UAT & Defect Control

Measured Results

Tools & Deliverables

Delivery Timeline

Consultant Takeaway

Strategic Pricing
& AR Configuration