Skip to main content
Founder experienceCustom SoftwareFinancial SystemsControlled Workflows

Organisation not identified - Professional experience

Audit-ready financial workflows: replacing an established spreadsheet process

In a technology-leadership role, I replaced an established spreadsheet process with an auditable workflow whose historical results reconciled exactly against independent evidence.

Published · By Timothy Indarsingh

Professional context

I completed this work in a professional role outside Firelinkx. The organisation and industry are omitted, and implementation details have been generalised. Firelinkx was not retained and did not deliver the project.

Role
Technology leadership
Delivery model
Professional work outside Firelinkx
Firelinkx involvement
None
Contribution
I specified, designed and built the financial workflow and its verification approach in a technology-leadership role.
Exact
Historical reconciliation
Immutable
History
Versioned
Rules
Checked
Approvals

Founder Experience

An established financial process carried by spreadsheets

The existing spreadsheet process was trusted because it had years of accepted results behind it. Replacing it required preserving that evidence while adding controls and traceability the workbook could not enforce on its own.

The spreadsheets were not a failed prototype waiting to be rescued. They contained operational knowledge and produced results the organisation understood. Their limits appeared in scale, continuity, approval enforcement and historical explanation.

The replacement therefore had to model separate sources of value, rules that change over time, corrections that remain visible, and workflows in which authority and independent review are distinct. Those principles are transferable to any financial process where today's answer must remain explainable years later.

The bar I set: independent history was the acceptance test

The hard part of replacing an established spreadsheet process is credibility. I set the success criterion before implementation: selected historical periods had to be recomputed through the real application path and match independently accepted outputs exactly.

That evidence was stronger than unit tests alone because it crossed the same boundaries the working system used. Exact reconciliation earned the right to replace the old process; immutable history, enforced approvals and reproducible as-at positions were the additional value.

The design decisions that carry the system

01

Ledger-first, everything derived

Append-only double-entry: every money movement is a transaction whose entries sum to zero. Nothing is edited or deleted; a mistake is corrected by a visible reversal and re-post. Balances are derived from the ledger, never stored as a master figure, which is what makes "show me the position as at any date" a natural query.

02

Money uses exact arithmetic

Fixed-precision values and explicit rounding rules keep calculations deterministic across storage, processing and reporting boundaries.

03

Effective-dated rules

Rules live in approved versions with validity windows, and each calculation resolves the version that applied to the event. A later change cannot silently restate history.

04

Independent approval is identity-based

Authority to approve is separate from independence. The system compares the acting person with the creator so broad permissions cannot erase the handoff.

05

Control evidence belongs in the workflow

Required evidence, reconciliation and approval are enforced at state transitions rather than left as reminders outside the system.

06

Preserve irreversible facts

The first release captures historical facts that cannot be reconstructed later while keeping speculative future calculations outside scope.

Specification began with observed evidence

I separated raw process evidence from the emerging specification so observed behavior, interpretation and design decisions could not blur together. The proposed model then went through adversarial review before implementation.

I accepted recommendations supported by the evidence, rejected others with written reasons and kept unresolved choices explicit. Decisions carried rationales and buildable defaults, which reduced rework without pretending every future variation had already been discovered.

Re-reading a system against its own principles

Late in the build I re-read the system against its stated principles rather than only its expected test cases. That review found places where implementation and intent had diverged quietly; all were corrected before release.

The useful question was not only whether the feature behaved as expected, but where the principle was enforced and what alternate path could bypass it. That adversarial alignment review is now a standing part of how I assess controlled systems.

What changed

01

The process left the spreadsheet

Key results are derived from an immutable history that records the action, actor, reason and approval instead of depending on one person's workbook knowledge.

02

Controls became structural

Independent approval, segregation of duties and evidence gates are workflow properties rather than steps someone must remember.

03

Historical results are independently reproducible

Exact reconciliation against accepted historical outputs made adoption evidence-based rather than trust-based.

04

Historical questions remain answerable

As-at positions can be reconstructed from immutable events instead of disappearing when a current value changes.

What replacing the spreadsheet actually required

The calculation engine was only the centre. Around it I built setup, staged opening positions, imports, allocation, exception handling, independent approval, period close, as-at reporting and document production.

The important design move was to model economically different events as different events instead of collapsing them into one editable total. That makes incomplete allocation, unresolved exceptions and reconciliation gaps visible by construction rather than dependent on somebody remembering a separate check.

An integrity routine and operations guide sit beside the interface because a financial workflow must explain how it is operated when nobody is clicking through a demonstration.

The deployment boundary was a product decision

The calculation core is isolated from interface and infrastructure concerns, which lets its rules and arithmetic be proved independently before any workflow can commit a result. The build widened from foundations and historical fixtures through one complete vertical slice, then into the remaining operating cycle.

Deployment boundaries and data handling were treated as product decisions rather than launch details. Version one also stayed disciplined: it implemented the evidenced calculation model, preserved facts that future models could require and left speculative calculations outside scope.

Transferable principles

01

Reconcile before replacing

Use independently accepted historical outputs as an integration-level release gate before asking users to trust the new process.

02

Make history and authority structural

Immutable events, versioned rules and identity-based approvals make financial explanations reproducible.

Capabilities Demonstrated

Automation & Custom SoftwareFinancial Systems EngineeringControlled Workflow DesignAudit-Grade RecordkeepingSpecification & Decision Records

Apply This Experience to Your Organisation

Firelinkx brings the founder's experience leading internal enterprise systems to independently contracted client work. Your project would be scoped, contracted and delivered separately by Firelinkx.