Skip to content

Architecture and consulting

A forecast the CFO can defend line by line

Three systems agreed on the size of the book and disagreed on how much of it was done. The gap was work physically finished and never billed.

Built for
SMT Research, Vancouver
Service line
Architecture and consulting
Window
Jun to Sep 2026
The headline number$2.7MOf finished work that had never been invoicedThe gap between what one system called installed and another called invoiced, on a book all three agreed the size of.

01Key numbers

What we measured

3Of work installed but never invoicedInstalled against invoiced. Derived from the two systems disagreeing, not from a new count.
97%Of cross-system transactions keyed4,506 transactions from 2010 to 2026, 97% keyed. The residue is itemised on the page, not absorbed.
4,506Of phantom revenue removed by refreshing dates115 of 154 open orders had an end date in the past or blank. The refresh lowered the forecast, it did not raise it.
12.4Months of backlog runwayA measured figure on the open book, published beside what remains and what was invoiced over the trailing twelve months. It is not the ratio of those two.
9The forecast openly refuses to vouch for49 orders past their end date and still counted as fully billable, plus 23 with no billing window at all.

02The situation

What was true before

The controller rebuilt the forecast by hand in Excel every quarter. Three systems disagreed on every number, and three conflicting definitions of remaining work were live in production at the same time.

Salesforce invoicing had only started in January 2026 and held 208 records. Every earlier invoice existed only in the accounting system, so no single query could see the whole history.

The first useful output was not a forecast. It was an arithmetic statement: all three systems put the book of work at the same size and differed only on how much of it was finished.

Contact us to find out more

Recognise this in your own org?

03What we built

The mechanism

A nightly Apex engine that writes one forecast row per order per month, and makes every row explain itself.

One join key across two retiring systems and a live one

A recompute joins 16 archive objects and the live invoice records on a legacy order key, then writes three financial fields per order. Everything downstream reads those three fields, so there is one definition of remaining work rather than three.

A five-tier priority spread that places every dollar

Finished work is dropped. Work with a billing window spreads across that quarter on an 80/20 billing-to-closeout split. Recurring work spreads evenly across twelve months. Undated work lands in the current month and is flagged. Legacy dates fall back to straight-line, with stale dates collapsing to now.

Every row carries the method that placed it

Each forecast row stores a method string saying exactly how that dollar got into that month. Revenue never lands in the past. Rounding drift is corrected on the last row rather than distributed silently.

Deduplication and anomaly rules stated as thresholds

An invoice is a duplicate if it falls inside the system transition window and matches another to the dollar within seven days. Outliers above a stated ceiling are excluded as a data error. Both thresholds are published, so a reader can disagree with the number by disagreeing with the rule.

A reconciliation bridge printed beside the headline

Backlog, less what is marked finished and never to be invoiced, gives what the engine actually spreads. Add open opportunities at 75% or better and the board headline follows. The arithmetic is on the page.

Sales and Forecasting
How the projection is built
Backlog, remaining to bill on open orders100%
Marked finished, nothing left to bill24%
=What the engine spreads across months76%
+Open pipeline at 75% or better, not signed2%
=Projected78%
What this number does not vouch for
49 ordersare past their end date and still counted as fully billable, with nobody having marked them finished.
23 ordershave no billing window at all, so their placement is the weakest rule in the engine.
9 orderswere invoiced past their contract value, and each one is named rather than netted off.
Depiction · A revenue forecast that prints its own arithmetic. Every row carries the method that placed its dollar, so a controller can defend the total line by line.The panel on the right is the part most forecasts omit: the amounts the engine will not vouch for, published beside the number rather than discovered in an audit.

Surfaces built

We will demonstrate any of these live, on the real org,.

  • The reconciliation bridge from backlog to board headlineImage withheld
  • Monthly forecast rows with the method string on eachImage withheld
  • The refuses-to-vouch-for panel naming its own weaknessesImage withheld
The finding

Refreshing the dates made the forecast smaller. That was the point.

115 of 154 open orders carried an end date that was in the past or blank. A structured refresh came back with all 153 answered. The stale-date bucket fell from 99 rows to zero, and the projected total fell with it. A forecast that only ever moves up is not a forecast.

04Outcome

What changed, verified

The engine reproduces the hand-built book to within rounding and publishes the arithmetic that gets it there.

  • The open book stated as contract, invoiced and remaining, each row carrying its method.
  • Matched the controller’s hand-built book to within rounding.
  • Pre-2026 records agree to the dollar on 54% of orders, with totals within 17%.
  • Nine orders were found invoiced past their contract value, and are named rather than netted off.
How it was verified

Reconciled against the accounting ledger across the live and completed eras. The unkeyed residue is listed by transaction.

Sources
  • docs/research/02-revenue-systems.md §2 · Projections
  • docs/research/02-revenue-systems.md §2 · The reconciliation bridge
  • docs/research/01-salesforce-platform.md §2.4 · Three-way reconciliation

Keep reading

Two more

All case studies
  • Architecture and consulting
    5 of 45Projects with any deposit accounting before we startedDeposits were held on roughly 45 projects. The org tracked them on five orders.

    Deposits, holdbacks and progress claims that reconcile

    Deposits, the standard 10% construction holdback and statutory declarations had no home in the org. The ledger that fixed it stores every amount as a positive number and puts the sign in the type.

  • Custom development
    31%Of quote lines carried no tax code5,997 of 19,255 lines. 5,182 of them sit on Canadian job sites.

    A tax engine rebuilt from 28 rows of configuration

    The client told us the tax was calculating by product instead of by province. We tested that against all 2,335 order line items and it was not true. Six other defects were, and we priced each one.

Next step

Bring us your hardest Salesforce problem

Tell us what is broken. You get a written read on it within one business day, before any money changes hands.

  • Reply within one business day
  • Live walkthrough of the org itself
  • Vancouver, British Columbia