The operational problem
Invoicing, payments, credits, expenses, compensation, profitability, forecasting, and tax preparation were fragmented across manual tools.
Built a local-first financial operating system for Que Media's invoices, payments, expenses, compensation, cash position, and internal review.
Why this system exists
One internal interface can explain what was invoiced, paid, outstanding, spent, and expected while leaving payment processors and accounting obligations in their proper roles.
The historical build combined invoices, payments, credits, expenses, compensation, profitability, forecasting, and tax preparation in separate live and demo SQLite databases. The original repository is not present in the current workspace.
How the work moves
- Create or import invoice
- Review and issue
- Record or reconcile payment
- Capture expense
- Classify and review
- Understand cash and client position
- Prepare accountant-facing records
What shaped the solution
Money could not use floating-point arithmetic.
Automatic feeds could not create a second source of truth.
Private invoices and financial values could not be exposed.
The useful local workflow came before speculative multi-user hosting.
What I owned
Designed
Financial domain model, live/demo isolation, invoice lifecycle, and review queues
Developed
Invoices, payments, credits, expenses, reports, forecasts, and audit history
Integrated
Historical imports; a Stripe adapter was reported in test mode but is not verifiable in current source
Tested
Money invariants, partial payments, credits, refunds, and safe demo states
Decisions that carried the work
Protect money with invariants
Amounts are represented in integer cents, and payment allocation is transactional so partial payments, credits, and refunds cannot silently drift.
Separate live and demo
Two isolated stores make demonstrations safe without risking real books or forcing fake data into production records.
Leave seams, not integrations
External feed adapters were designed where useful, but unnecessary vendor sync was deferred until an operating need justified permanent complexity.
Verified outcome
Created one operating view across invoicing, payment, expense, compensation, profitability, forecasting, and audit workflows.
Separated private books from a realistic demo database.
Historical import and automated-test evidence exists, but the current repository is unavailable for verification.
What I will not overclaim
QFlow remains local-first and its original repository is not present in the current workspace. Stripe test-mode work was reported but is not verifiable in current source. Bank, card, email, and broader reconciliation work is not presented as complete. No financial records are published.
Verified from the QFlow handoff, July 2026 implementation session, and FDE evidence analysis. Private values and recorded credentials are excluded.