Case study · Clinic operations
Every recorded transaction has a name, a time, and a trail.
BrightSmile is a mobile-first clinic operations system designed to preserve who recorded a transaction, when the financial event actually happened, when it was encoded, and how it flows into reporting and reconciliation.
- Accountability
- Financial control
- Operational visibility
The problem
When records live in five places, the trail disappears.
When clinic transactions are split across receipts, chat threads, notebooks, forms and spreadsheets, management can lose the connection between the transaction, the person who recorded it, and the financial report it eventually reaches.
- No attribution. Who entered it, when, and where did the evidence come from?
- No control point. Does what the system expects actually match what was counted?
- Limited visibility. Management spends time reconstructing activity instead of reviewing a structured record.
The solution
One entry point. One record. One trail.
Staff record the transaction once. From there the system carries it — into a durable record, an audit row, the reporting rollup, and the daily comparison against counted cash.
- Staff entry
- Supporting record
- Transaction history
- Audit trail
- Financial reporting
- Reconciliation
Walkthrough
4:03
Watch the full workflow.
Follow one synthetic ₱3,250 clinic expense from staff encoding through transaction history, audit trail, financial reporting and management controls.
- Runtime4 minutes 3 seconds
- DataSynthetic throughout — a fictional clinic and a generated receipt
- PlaybackPress play to load; the page itself stays light
Staff entry
Entry is where the quality of the record is decided.
The form asks for what makes a transaction reviewable later, and stops there.
- Required financial fields. Date, category, amount and payment mode are marked and validated before a submission is accepted.
- The transaction date is editable. It records when the financial event happened — not when the form was opened.
- Payment mode is captured at entry. This allows cash, GCash and other payment streams to remain distinguishable downstream.
- Notes and multiple line items. One supply run stays a single submission with itemised detail rather than several disconnected entries.
- Receipt support. A supporting receipt can be attached directly to the transaction record.
Transaction record
The record keeps what happened and who recorded it.
Two layers of fact are preserved on the same record — the submission, and the transaction inside it.
- Submission. Encoded 08/12/2026 by mia.santos@brightsmile-demo.example — 1 item, ₱3,250.00.
- Transaction. DENTAL SUPPLIES · 07/31/2026 · GCash · Composite refill · ₱3,250.00.
- Supporting receipt stays attached to the record and is viewable from it.
- Corrections are explicit actions — edit, replace the receipt, or remove — alongside a void log and an activity log.
- Records stay findable through search, date range, category and payment-mode filters.
Audit trail
Who did what, to which table, for how much.
Below is one table read across three horizontal scroll positions — not three different logs. Follow the last row, 08/12/2026 15:48:01, from left to right.
Tap any capture to read it at full size.
08/12/2026 15:48:01 · mia.santos · CREATE · App_Submissions · ₱3250 — DENTAL SUPPLIES
One row, written by the system rather than typed by a person, holding the whole event.
Financial reporting
Reporting is derived, not re-encoded.
The reporting views are derived from the same underlying transaction records, reducing the need for separate re-encoding.
- Revenue is split by source — clinic sales, other revenue, HMO and X-ray each carry their own line before rolling into total sales.
- Expenses are split by payment mode, so cash and GCash remain visible as separate streams.
- X-ray is tracked separately on both the revenue and the expense side.
- Why the separation matters. Cash and digital money are held and verified differently — one is counted in the clinic, the other sits in an account with its own balance. Keeping them apart is what makes each of them checkable.
Financial control & reconciliation
A record that is never checked is only a claim.
Each operating day compares what the system expects against what was actually counted, then marks the day BALANCED or VARIANCE so management knows where to investigate.
These two captures are from different months and are unrelated to the ₱3,250 example below — they are here to show the control itself. A variance stays visible, dated and attached to a single day, instead of being absorbed into a month-end total.
Worked example
One synthetic ₱3,250 expense, followed end to end.
The same transaction shown in the screenshots above and in the walkthrough. It is synthetic demo data — the supplier, the account and the receipt were generated for demonstration.
-
Entered on a phone
The transaction date is set back to the day the money moved, the item is filled in, and a receipt is attached.
Date Jul 31, 2026
Category DENTAL SUPPLIES
Amount ₱3,250.00
Mode GCash
Notes Composite refill
Receipt attached -
Becomes a record
It appears in Expense Records under a submission stamped 08/12/2026 to mia.santos, while the line item keeps its own transaction date of 07/31/2026.
-
Writes an audit row
08/12/2026 15:48:01 · mia.santos · CREATE · App_Submissions · ₱3250 — DENTAL SUPPLIES
-
Lands in the financial record
The amount appears in the July 2026 expense records as a GCash expense dated 07/31/2026 and flows into the GCash side of the cashflow summary.
Two dates, on purpose
- Transaction date
- July 31, 2026When the financial event happened
- Encoded at
- August 12, 2026 · 15:48:01When a named user recorded it
The system stores both and shows both. The transaction date is what the books are built on; the encoding time is what accountability is built on.
Collapse them into one field and a record written twelve days later looks identical to one written the same afternoon. Keeping both is what makes a late entry traceable rather than invisible.
Business outcomes
What this system changes operationally.
These are properties of the system shown above. No client results, performance figures or ROI are claimed.
-
Clear attribution
Every recorded action carries a user and a timestamp.
-
A daily control point
Expected and counted balances can be compared and exceptions surfaced.
-
Cash and digital money stay distinguishable
Payment channels remain separated through reporting.
-
Evidence stays with the record
Supporting receipts can remain attached to the transaction.
-
Late entries remain traceable
Transaction date and encoding time are preserved separately.
-
Role-aware access
Staff entry and management review functions are separated.
-
Reduced re-encoding
Operational records feed downstream reporting.
-
One place to investigate
History, audit activity, reporting and reconciliation are connected.
Architecture
Simple to operate, strict where it writes.
Staff work in a phone app. Everything that changes a financial record passes through a controlled layer before it reaches structured data that management can read directly.
- Mobile PWA
- Secure API layer
- Backend automation
- Structured financial data
- Management views
- Role-aware access — entry and review functions are separated.
- Audit logging — recorded actions are written with user, time and detail.
- Receipt handling — supporting images stay attached to their records.
- Duplicate-write protection — guards against the same submission landing twice.
- Structured financial records — readable and exportable without the app in front of them.
- Management reporting and reconciliation — built on the same records staff create.
Built on Google Apps Script and Google Sheets, with the demo served as a static front end behind a controlled API layer. Implementation details of the security layer are deliberately not published here.
Portfolio disclosure
BrightSmile Dental Center is a fictional clinic. Every name, amount, supplier, receipt and record on this page is synthetic and was generated for demonstration.
The screenshots are unretouched captures of an isolated portfolio demo, which runs on its own project and its own data. No real clinic records, private information or client books appear here in any form.
No client results, performance metrics or ROI figures are claimed. What is shown is the system and how it behaves.
Next
Still relying on repetitive manual encoding or disconnected records?
I design business systems around the way your team actually works — connecting daily operations, accountability, reporting and management visibility.