Ledger Copilot
Get started
Sign in

/gov · Case studies

How a switch would run — three modeled scenarios.

We don't have named customers yet, and we won't imply otherwise. These are modeled deployments: fictional agency profiles built from public industry benchmarks, walked through what the platform actually does. No interviews, quotes, or pilot dates stand behind them — when real case studies exist, they replace these with names and customer-approved numbers.

⚠Modeled scenarios — not customers. Numbers are modeled assumptions built from our calculator methodology and industry-benchmark labor + error rates — not measurements from deployments.

Small SMB PHA

Riverbend Housing Authority (modeled scenario)

Modeled scenario — no customer behind it
480 HCV vouchers·0 PH units·$8.40M annual revenue
Modeled incumbent stack: PHA-Web (HCV module + Inspections) · QuickBooks Online (separate bookkeeping) · Excel + email for board reporting

Modeled situation

A modeled small agency: 480 HCV vouchers in a single state-funded region, a finance team of 2 plus a part-time bookkeeper. Compliance lives in PHA-Web, bookkeeping in QuickBooks — and the two never agree without hours of manual reconciliation that breaks down completely at year-end audit. A common small-PHA profile.

Scenario trigger

The scenario trigger: recurring HAP-payment discrepancies between bank disbursements and the HAP register that surface during single audit as a material weakness — the classic two-system failure mode this product is built around.

How the deployment would run

  • •Connect the operating + reserve accounts — OFX Direct and statement upload work today with no vendor activation; Plaid bank feeds switch on once production access is activated — and turn on bank reconciliation in week 1
  • •Import the HAP-register history and reconcile it against bank statements line-by-line, so prior discrepancies surface with an audit trail instead of a year-end scramble
  • •Keep PHA-Web authoritative for HUD-50058 submission — the platform never files to HUD — while taking ownership of the GL, bank rec, and audit prep underneath it
  • •Run the audit engine at every close — deterministic and cheap enough to re-run constantly, producing fingerprinted, re-runnable reports (unattended scheduled runs are roadmap)
  • •Hand the auditor a read-only account and a continuously-reconciled record set instead of a binder assembled the week before fieldwork

What the platform delivers

Bookkeeper reconciliation work
Cut
replaces manual two-system reconciliation with continuous bank rec
Audit-prep effort
Reduced
year-end audit packet assembled from continuously-reconciled records, not a year-end scramble
Reconciliation lag
30d → on demand
reconciliation re-runs in seconds whenever the books change; monthly close stops being a scramble
Audit findings surfaced in-period
Yes
flags discrepancies between bank disbursements and the HAP register on every audit run, before the auditor does
Modeled time to stand up
~1 week
bank connection + reconciliation running in the first week (modeled assumption)
Deployment scale
One engine
one platform across the modeled range — small SMB PHA to a large metro profile

The outcome this scenario is engineered for: the agency doesn't replace PHA-Web — it adds the reconciliation layer underneath it that should have always been there, so the auditor notices the difference before the board does.

Modeled rollout: week 1 connect + reconcile; month 1 running in parallel with the existing close; the legacy bookkeeping system retires at its own renewal date, not before the numbers tie.

Mid-County PHA

Mid-County Housing Authority (modeled scenario)

Modeled scenario — no customer behind it
920 HCV vouchers·80 PH units·$14.20M annual revenue
Modeled incumbent stack: PHA-Web (full platform) · Yardi Voyager (multifamily side) · Outlook for staff coordination

Modeled situation

A modeled mid-size agency: HCV plus a small Public Housing portfolio, 4 finance FTEs and a Compliance Officer, a SEMAP score drifting down for three years and sitting just above the Standard line with several indicators below their thresholds. Penalty exposure concentrates in late FDS and SEMAP deductions.

Scenario trigger

The scenario trigger: a HOTMA implementation deadline the incumbent toolkit can't model — the agency can't quantify the per-tenant impact of the asset-cap rule across its roster before the compliance date.

How the deployment would run

  • •Run the HOTMA batch asset-cap + TTP screen across the full 920-family roster to quantify exactly which families cross the cap, whose rents change, and who becomes ineligible — in hours, not a vendor release cycle
  • •Keep the SEMAP self-assessment worksheet current at each close so indicators trending below threshold surface before the recertification deadline, not after
  • •Run the audit engine over the AP ledger at each close so duplicate vendor payments are flagged within the period instead of at year-end
  • •Generate the board packet from the books on a schedule (export to Excel/CSV for distribution through the agency's own Microsoft 365)
  • •Draft the FDS from the general ledger well ahead of the submission window, tied out to the financials — the agency reviews and submits through HUD's own portal, as always

What the platform delivers

Admin + audit workload
Reduced
cuts finance-team hours on audit prep and board reporting
SEMAP self-assessment
Worksheet
self-scores the indicators and surfaces ones below threshold before the recert deadline
HOTMA exposure
Modeled per-family
models the asset-cap impact across the full roster so remediation can run before the HUD deadline
Duplicate-payment detection
On every run
the audit engine flags duplicate vendor payments each time it runs
Board reporting cycle
Repeatable
board packet generated from the books on demand, no incremental staff time
FDS readiness
Weeks early
FDS draft generated well ahead of the submission deadline, tied to financials

The outcome this scenario is engineered for: when a compliance deadline like HOTMA lands, the agency answers its own roster-level questions the same week — instead of waiting on an incumbent vendor's release calendar.

Modeled rollout: HOTMA screen + SEMAP worksheet in the first weeks; continuous audit and FDS drafting layered in over the first quarter; PHA-Web stays authoritative for submissions throughout.

Large Metropolitan PHA

Metropolitan Housing Authority (modeled scenario)

Modeled scenario — no customer behind it
14,500 HCV vouchers·6,800 PH units·$85.00M annual revenue
Modeled incumbent stack: PHA-Web (full platform, multi-site) · Sage Intacct (general ledger) · Yardi (property management) · ServiceNow (work orders) · Office 365 federated SSO

Modeled situation

A modeled large agency: one of the bigger HCV programs in the country plus a substantial Public Housing portfolio, a Troubled designation from a prior PHAS cycle, a federal Recovery Plan with monthly HUD field-office check-ins, and 22 finance FTEs spread across HCV, PH, and Capital Fund administration.

Scenario trigger

The scenario trigger: a Recovery Plan milestone that requires demonstrating sustainable improvement in the PHAS Financial and Management pillars — and no internal way to produce a live PHAS composite forecast between annual scores.

How the deployment would run

  • •Model the PHAS composite across the four pillars so the drivers of the score are explicit between official scores — today this is a calculator over entered pillar inputs; feeding it live from the agency's own books is roadmap
  • •Compute the Capital Fund obligation + expenditure deadline clocks (the 24-month / 48-month windows) per grant, so end dates surface with time to act — obligation-rate tracking against the grant ledger is roadmap
  • •Reconcile the full account set (OFX Direct + statement upload today; Plaid bank feeds once production access is activated) so multi-account manual reconciliation disappears
  • •Estimate NSPIRE deduction exposure from the inspection team's defect counts — a readiness estimator your staff feed, not an automated property scan
  • •Export the PHAS model and the books-derived reports (Excel/CSV) for distribution to the executive team and audit committee through the agency's own Microsoft 365

What the platform delivers

Finance-team workload
Reduced
eliminates manual reconciliation across a multi-account treasury
PHAS composite model
Calculator
models the four-pillar composite from entered inputs; live books-fed forecasting is roadmap
Recovery Plan reporting
Supported
an explicit, re-runnable PHAS model to bring to milestone reviews
Bank reconciliation
Automated
statement import + OFX Direct today (Plaid pending production activation); manual two-system reconciliation eliminated
Capital Fund deadlines
Computed
24/48-month obligation + expenditure clocks per grant; rate tracking against the ledger is roadmap
NSPIRE readiness
Estimator
deduction-exposure estimate from your team's defect counts; not an automated scan

The outcome this scenario is engineered for: a Troubled agency in Recovery gets an explicit, re-runnable model of the numbers HUD scores it on — so milestone reviews are about progress made, not data assembled.

Modeled rollout: a longer foundation phase than the small-PHA scenario (larger data volume, multi-site reconciliation), with the PHAS model as the first deliverable and cutover decisions deferred until the numbers tie under parallel run.

Reference customer program

Be the first case study.

We're recruiting reference customers — small, mid, and large PHAs. Reference-customer terms in exchange for case-study rights and a reasonable number of reference calls. We do the analytics and the writeup; you approve every word before publication. No slots are reserved and no pilots are in flight: whoever starts first is genuinely first, and gets the leverage that comes with that.

Estimate it with your own numbers →

A note on transparency

Rather than fabricating named agencies, interviews, or pilot timelines, we're showing you the structure of the deployment, the capabilities we'd document, and the methodology behind any numbers — with each capability described at its real maturity (shipped, calculator, or roadmap) so you can verify it against the product today.

There are no pilot customers to take a reference call yet. The day that changes, this page will say so — offering calls with customers who don't exist is exactly the kind of vendor behavior this product is built to replace.