30-day working version: bank statement review for Margin Wheeler

1. What you asked for

You picked bank categorisation from historical treatment, and asked for an outcome-focused 30-day scope on real files, with before and after measured and acceptance at the end.

On 15 August you named the workflow:

Bank statements uploaded → transactions automatically extracted → system looks at the client's historical accounting treatment → recommends the appropriate account/category and GST treatment with a confidence level → accountant reviews primarily the exceptions/low-confidence items → output is structured and ready for QuickBooks Desktop.

On 17 August you set the bar:

From our perspective, the important thing is that we don't just end up with something that technically works, but something our Accounts team would genuinely want to use because it meaningfully improves their workflow.

Margin Wheeler has more than twenty people in Accounts. Bank work today is daily manual keying into QuickBooks Desktop. The accountant stays the final reviewer throughout. This scope is that workflow, built and measured in 30 days.

2. What you get for S$5,000

1. A working version of the bank-review path, on real client files, operated by your own people. Statements in, transactions extracted (failures shown, not hidden), category and GST recommended from each client's approved history with a confidence level, review that puts exceptions first, and a structured export matching the QuickBooks Desktop import template you use today. Nothing posts to QuickBooks on its own. The accountant accepts, corrects, or rejects every line.
2. A measured before-and-after readout: six pass/fail tests (section 4), scored on statements the system was never tuned on.
3. Kickoff at Jurong East, then onsite with your Accounts team two days a week (eight committed days after kickoff, and more when the work calls for it). I build in the loop with the people who will use it, not off-site against a spec.
4. The source code, export templates, and a written run guide, handed over at day 30. It runs on your machines. You keep all of it whatever you decide.
5. A 14-day warranty after delivery (section 5).
6. S$2,500 of this fee credited to any follow-on build signed within 30 days of delivery.

3. How the 30 days run

Starting. Signing and the 50% deposit reserve your 30-day slot. The clock starts when the remaining start conditions are in, within 14 days of signing: a named practitioner, a named reviewer, the agreed sample of real statements and approved historical books (approved, redacted, or sandboxed, within the caps in section 7), and your QuickBooks Desktop version plus the import template you use today. If the start conditions can't be assembled within 14 days, either of us can call it off and the deposit comes back in full. You never pay for a clock that didn't start. Until real files arrive, I work on synthetic files only.

The month. Building is the certain part. What decides day 30 is whether your Accounts team trusts it, understands it, and would rather use it than the current path. So the month runs as one loop, not phases:

• I start from the working model you have already seen (synthetic files) and sit with your named users on the onsite days, watching real bank work.
• The path you described is the starting design. I adapt it with your users rather than freezing it as a spec on day one: put a slice in front of them, watch them drive it, fix what they don't trust or don't understand, repeat.
• As soon as a slice is usable, they operate it themselves, first on synthetic files, then on the approved real sample. Each week the loop covers more of the real thing: extraction, historical category and GST, confidence, exceptions, export.
• When your sample files arrive, we split them on day one: a working set I build and tune against, and a test set I put aside and never open while building, like an audit sample. In the final week, your named users run the test set through the system themselves, without me at the keyboard. The six tests in section 4 are scored on that run, so the result shows how it handles fresh files in your team's hands, not how well I tuned it to examples I had seen.
• More Accounts people trying it during the month is welcome, as long as they are people you name and we stay inside the file caps.

If your side gets busy after the clock starts, the clock pauses with you. You never lose paid days to your own peak weeks. Any change to the scope itself is a short written revise before extra work, so the fee stays honest.

4. How we know it worked

Early in the month we record the baseline (your practitioner doing today's manual path, timed), the answer key (entries from approved books your team has already confirmed correct), and the error types you rank most costly (your team names the mistakes that would hurt most if they slipped through, for example a wrong GST treatment, or an inter-company transfer booked as income). Later in the month, once the working set shows what your history can support, we agree one more number: the minimum coverage, the share of lines that should get a correct recommendation instead of going to exceptions (counting only lines your history can actually support). All four are agreed in writing before the test set is opened. Day 30 is scored against them, on the test set only. Six pass/fail tests:

1. Speed. Reviewing with the working version is not slower than the timed baseline, same practitioner, same kind of statement.
2. The costly lines get flagged. Every line in the test set that belongs to your named highest-cost error types lands in the exceptions list. None slips through as a confident recommendation.
3. Extraction. Date and amount match the answer key exactly, every line.
4. Category, GST, and coverage. Every confident recommendation matches the answer key exactly, on both category and GST; a confident wrong answer is a fail, even a rare one. And at least the agreed share of lines gets a correct recommendation instead of going to exceptions: a version that sent everything to review would be safe but useless, and it fails this test.
5. Import. Your named reviewer imports the test batch for one agreed entity into a test copy of that company file (a restored backup), on their machine, usual import path, no re-keying by hand. Live books are never written to.
6. Your team runs it. The named users complete the test batch themselves, without me driving.

Alongside the six tests, day 30 records the human answer: can your named users run it alone, can they explain why a line was recommended or flagged, and do they prefer it to the current path on the timed sample. I will report that answer straight, including if it is no. The point of the month is a true reading, not a demo-day performance.

5. Price and terms

Fee: S$5,000 fixed, in SGD. Invoiced by Kuan Yu.

Deposit: S$2,500 (50%) on signing. Reserves the slot; refunded in full if the start conditions aren't in within 14 days and either side calls it off.

Balance: S$2,500 on day-30 delivery of the working version and the written readout, due within 7 days.

Day 30 ends with your written call: go, revise, or stop. That call decides the next piece of work. The balance is owed on delivery of the working version and readout. What protects you on that: the six tests are objective, scored on your files, run by your people; any test the delivered version fails in runnable form is fixed under warranty; and if you continue, half this fee comes back as credit.

Warranty: 14 days of defect-fixing after delivery. A defect is a runnable day-30 test the delivered version fails. New statement formats or a second workflow are new scope, not defects.

Credit: sign a follow-on paid build within 30 days of delivery and S$2,500 is credited against it. You keep the working version and everything in section 2 either way.

This offer stands until 2 September 2026.

6. What I need from you

• The start conditions in section 3: named practitioner, named reviewer, the sample and historical books, your QuickBooks Desktop version and import template. Near day 30: a test copy of the agreed entity's company file (a restored backup) for the import test.
• Time. You: about two hours at kickoff, 30 minutes a week, an hour at day 30. Five to six hours across the month. Your named users: kickoff plus the eight onsite days, driving the current slice and reacting in the session while they keep doing their jobs. I sit with the work; there is no homework. Those hours are the minimum the month needs, not a cap on your involvement; you are welcome closer to the work whenever you want.
• Decisions in the room or within a few days: which error types cost you most, which slice to try next, and the day-30 call. A stuck decision pauses the clock rather than stretching the month.
• Straight feedback. If a recommendation looks wrong or the flow feels off, the most useful thing your team can do is say so in the session. I would rather hear it on day 6 than day 30.

7. Boundaries, data and ownership

In scope: one path, bank statements only: intake, extraction, historical category and GST with confidence, exceptions-first review, structured export. Human-gated throughout.

The fee covers:

The file caps cover the working set and test set together. Past a cap, we do a short written revise before the extra work, so nothing surprising lands on the invoice.

Out of scope: autonomous posting; multi-department automation; training on unapproved or production data; a generic portal; a product for other firms; automatic statement collection; payment or salary vouchers; production guarantees from a synthetic demo. Any of these that matters to you can be scoped as its own piece after day 30.

Data. Margin Wheeler is the data controller; I process files for this engagement only. Only approved, redacted, or sandboxed client files plus the agreed historical books are processed, onsite at Jurong East and on my machine. No third-party model training on your files. No cloud service touches your files without your written okay, and if one is used, its ongoing cost is named at handover and sits with you after day 30. No production posting, no production QuickBooks write, no live credentials; the import test runs on your reviewer's machine against a restored backup or test copy, never the live file. I delete all client files and derived copies within 14 days of the engagement ending, or sooner on request (a signed follow-on continues data access under its own terms). Your files and answer key are never reused for another customer.

Ownership. Yours: your data, your answer key and historical books, and the delivered working version with its source, templates, run guide, and readout. Handover includes a plain list of what it runs on: machine and OS assumption, language and version, third-party libraries and their licences, any model or API and who pays for it after day 30, and what is not included (QuickBooks Desktop itself, your chart of accounts, production hosting). Mine: the underlying methods and tools built before or outside this engagement, licensed to you royalty-free as needed to run the delivered version internally for Accounts. Internal use for your team; not for resale or repackaging as a product to your clients. In plain terms: you keep everything needed to run and own the result; I keep the general-purpose machinery and what building it taught me; your files and answer key are never part of what I carry to anyone else.

It runs locally on your machines with no hosting on my side, so you are not locked into me to keep using it. If you would rather I host or maintain it, we can price that separately after day 30.

8. Next step

1. Reply that this scope and price are the ones to walk through.
2. Twenty minutes, on this thread or a call.
3. Kickoff at Jurong East once the start conditions are in.

If the 30 days go well, other projects or something more substantial can follow. That conversation happens after delivery, on the day-30 evidence.