Workforce operations platform with a prepaid-hours billing ledger

A staffing business that sells hours in advance is running a live prepaid balance per client engagement, mutated by purchases, credits, refunds, transfers, automatic top-ups and time draw-downs — some of which settle asynchronously through a payment provider — and if that number drifts, either the client is over-billed or the business gives away work. Every hour recorded also has to produce two different money outcomes at two different rates: what the client is billed and what the contractor is paid, both of which must survive a later rate change without rewriting history. Contractors record time across time zones against their own local clock, timers get left running overnight, and a document database with no joins or aggregations can't answer the pay-period, per-contractor and transaction questions the business actually asks.

Modelled the balance as an append-only ledger rather than a mutable field: every movement — purchase, credit, refund, transfer, top-up, draw-down — writes an immutable record carrying the adjustment, its monetary value and the balance before and after, so the stored balance is a cached projection of history rather than the source of truth. All hour and currency arithmetic runs through an arbitrary-precision decimal library on both client and backend, with precision validated on every quantity entering the system, and both the client rate and the contractor rate are snapshotted onto the timesheet at creation so a later rate change can't retroactively alter historical billing or payroll.

Before the nightly run converts approved time into a billing draw, it applies a set of review rules and routes anything unusual into a pending state for a person to check rather than processing it silently. Payment charges are written at initiation in a pending state and only credited to the balance when the provider's webhook confirms settlement. Two independent top-up models — a calendar-interval reload and a balance-threshold reload — share one charge path, and threshold top-ups are evaluated immediately after each billing run so a reload never fires against a stale balance. Because the operational document store can't aggregate or join, a hosted search index and an analytics warehouse are maintained alongside it by triggers, so reporting and cross-entity filtering never compete with user-facing traffic — and every report is a declarative definition with a parameterised query rather than hand-written SQL scattered through the codebase.

Hours worked, hours billed and hours paid for come from one record, closing the reconciliation gap between time tracking, invoicing and payroll. The prepaid balance is explainable at any point because every movement is an immutable record showing what changed and the balance on either side of it, clients stop running out of hours unexpectedly because top-ups fire automatically, and anomalies reach a person before they reach an invoice instead of being discovered after the fact.

Something holding you back?

New build, rebuild, or adding AI to what you already have — I'll take a look and give you an honest perspective.