Demo Advisory Partners LLP: a consulting engagement from sale to close

This demonstration follows a fictional consulting firm implementing a multi-country retail ERP. It shows how OSERP separates a promise, approved work, billable evidence, invoice, cash, and recognised revenue. The names and amounts are training data. Always confirm the configured product release and accounting policy before using the pattern in a real engagement.

The engagement brief

Demo Advisory Partners LLP signs a six-month implementation contract with Demo Retail Group LLC. The contract is worth USD 180,000: 30% mobilisation, 40% after configured conference-room pilot, and 30% at production go-live. Consultants work from India, the UAE, and Saudi Arabia. The customer is billed in USD, while local expenses are paid in INR, AED, and SAR. The firm must report project margin in its leading book and explain unbilled work, advances, retention, and foreign-exchange differences.

The project manager creates the customer, contract, project, manager, start/end dates, currency, billing model, and approval matrix. The contract is not a posted sale. It is the commercial authority from which budgets, work packages, timesheets, expenses, milestones, and invoices derive.

Project and WBS setup

The project DRG-ERP-2026 is divided into discovery, design, configuration, data migration, testing, training, and go-live. Each WBS element has a manager, planned dates, budget, cost code, and postable status. Headings are for navigation; only approved leaf elements should receive cost postings.

Field	Example	Purpose and impact
Project code	DRG-ERP-2026	Stable reporting key across documents
Customer	Demo Retail Group LLC	Connects receivable and statements
Contract value	USD 180,000	Commercial ceiling, not automatically revenue
Base currency	USD	Billing and project margin currency
Manager	Maya Rao	Accountability and approval routing
WBS element	03-CONFIG	Attributes time, expense, and budget
Cost code	CONSULTING-IMPLEMENT	Consistent margin analysis
Billable flag	Yes/No per work item	Prevents internal time leaking to customer billing
Budget	Hours and amount	Compares plan, actual, committed, and forecast
Status	Draft, active, on hold, closed	Controls which operations are allowed

The manager publishes the WBS only after reviewing which elements can receive postings. Renaming a WBS label is not a substitute for correcting a wrongly coded posted document; the audit trail must remain understandable.

Resource, rate, and access design

People are assigned by role and country. Maya is the engagement partner, Arjun is a functional consultant, Sara is a data lead, and Omar is the customer-side approver. Each consultant has a cost rate and one or more bill rates. A rate card version carries effective-from/effective-to dates, currency, role, customer, and project overrides.

The firm separates cost rate from bill rate. Cost rate answers “what did this resource cost the firm?” Bill rate answers “what may be charged to the customer?” Mixing them produces a false project margin. Project permissions allow consultants to see their work while the manager sees the full engagement and finance sees financial fields.

Discovery and time capture

During week one, Arjun records 32 hours against 01-DISCOVERY, Sara records 18 hours against 02-DATA-MIGRATION, and Maya records 6 hours of partner review. Each time entry needs date, employee, project, WBS, activity, hours, billable flag, description, and evidence or work-note reference. A time entry is not billable merely because it has hours.

The consultant submits a weekly timesheet. The manager checks date, WBS, hours, duplicate entries, billability, rate card, and customer scope. Rejected time returns for rework with a reason. Approved time becomes eligible for billing or internal cost recognition according to the configured policy. The approval event and the invoice event are separate facts.

Expense capture across currencies

Sara pays AED 1,250 for a customer workshop room, Arjun pays INR 18,400 for travel, and Maya pays SAR 950 for a Saudi site visit. Every expense records employee, date, currency, amount, tax, category, project, WBS, receipt attachment, business purpose, and billable decision. The dated exchange rate translates the cost to the project currency; the original amount remains evidence.

An expense without a receipt may be held or rejected by policy. A receipt upload is not permission to charge the customer. The manager approves the business purpose and project coding; finance approves tax and reimbursement; billing decides whether the customer invoice includes it.

Milestone billing and advance

At signature, finance raises the 30% mobilisation invoice: USD 54,000. The invoice records customer, contract, milestone, invoice date, posting date, due date, currency, tax treatment, payment terms, and allocation reference. The advance is a receivable and cash event; it is not automatically the same as earned revenue. The revenue policy determines whether it is deferred and released by milestone, percentage of completion, or another approved method.

At the end of design, the project manager submits the conference-room pilot milestone with completion evidence, approved deliverables, open risks, and a completion percentage. The customer approver signs the evidence. Only then does billing create the 40% invoice. The final 30% follows the go-live acceptance document. A consultant should be able to trace each invoice line back to its WBS, milestone, acceptance, and contract version.

Revenue recognition and work in progress

If policy recognises revenue over approved milestones, finance creates a schedule with source document, total amount, number of periods or milestones, start date, deferred ledger, revenue ledger, and project dimension. The schedule preview is reviewed before Run generates entries. A deferred account is a liability; a revenue account is income. Cancelling a schedule stops remaining recognition but never erases journals already posted.

Unbilled approved hours and expenses remain visible as work in progress or unbilled receivable according to policy. The project report must distinguish:

Contract value       180,000 USD
Invoiced to date      126,000 USD
Collected to date      90,000 USD
Approved unbilled      14,500 USD
Forecast cost          92,000 USD
Forecast margin        88,000 USD

These are different measures. Invoiced is not collected. Approved work is not necessarily invoiced. Forecast margin is not posted profit.

Change request and control

The customer asks for an additional warehouse integration. The consultant creates a change request with scope, hours, rate, currency, delivery date, risk, and commercial value. It is approved before the team works. Adding hours to a timesheet without an approved variation hides a margin decision in an operational record.

The approval matrix can route low-value changes to the project manager and larger changes to the partner. Hold, reject, rework, reassign, ask, and watch have different meanings. Ask and watch do not approve. A project reaching “active” does not prove the variation is billable.

Collection, FX, and close

The customer pays USD 90,000 by bank transfer. Finance records bank account, receipt date, currency, exchange rate, reference, and allocation to the oldest approved invoices. The allocation clears receivable; the bank statement proves settlement. A partial or short payment remains open with a collection action and reason.

At month end, finance reviews project statement, invoice ageing, unbilled work, deferred revenue, expense claims, FX differences, WBS budget-versus-actual, and open approvals. The project is closed only when deliverables are accepted, invoices are raised, receipts are allocated, remaining WBS balances are explained, and no time or expense draft remains.

Consultant handover checklist

Hand over the contract version, project/WBS tree, rate-card versions, resource access, approval routes, sample approved/rejected timesheets, expense evidence, milestone acceptance, invoice chain, revenue schedule, collection allocation, FX policy, and close report. Record what is product behavior, what is tenant configuration, what is accounting policy, and what remains an extension requirement.

Use this case with Projects and approvals, Sales lifecycle, Advanced GL Mapping, and API Library. The same evidence template will be reused for manufacturing and hospitality cases.