Who may act?
Firebase identity, workspace membership, and roles decide who can review, approve, or sync a bill.
Applied AI case study / 2025—present
An invoice can be read correctly and still create the wrong bill.
I built SyncABill to turn emailed and uploaded invoices into reviewable accounting records. Gemini reads the document. Deterministic code controls what happens next.
PRODUCT TOUR / 71 SECONDS
From one invoice to a bill ready for review.
The demo follows an invoice through upload, extraction, arithmetic checks, source review, correction, and approval. It uses a fictional company and sample document, so no customer data appears in the recording.
04invoice intake paths
02accounting integrations
01controller-owned review policy
00model-authorized financial writes
01 / THE WORKFLOW
The model reads. The application decides.
Invoices arrive by upload, forwarding, Gmail, or Microsoft 365. Before Gemini runs, SyncABill checks the file, rejects exact duplicates, reserves plan usage, and keeps the original document for review.
The product uses a React/Vite frontend and TypeScript and Node.js services on Firebase Cloud Functions. Firestore carries tenant, invoice, job, lock, and audit state. Cloud Storage holds source documents, while Firebase Auth, App Check, and Secret Manager protect client calls and provider credentials.
01Receiveemail, inbox, or upload
→
02ExtractGemini returns structured fields
→
03Checkrules, arithmetic, and accounts
→
04Syncapproved bill reaches the ledger
The model proposes vendor names, dates, totals, line items, and expense accounts. Application code checks the response, resolves the account against the real ledger, and applies the controller’s review rules before QuickBooks Online or Xero receives it.
02 / WHY THE SHELL MATTERS
A fluent answer is not permission to move money.
Does the bill add up?
Ordinary code checks totals and confirms that suggested accounts exist in the connected ledger.
Should a person see it?
The account controller sets the review policy. The model does not choose its own level of oversight.
Will a retry create two bills?
Content hashes, operation locks, duplicate checks, and provider idempotency protect the manual sync path.
03 / SECURITY
Financial documents make security part of the product.
I completed Google’s CASA Tier 2 security assessment and brought SyncABill to SOC 2 readiness. The product uses least-privilege OAuth, encrypted provider credentials, signed uploads, role checks, audit events, and bounded retries.
MODEL OUTPUT
A candidate set of facts parsed from an untrusted document.
APPLICATION DECISION
A checked, authorized, recorded action with a visible failure state.
CASA Tier 2 is a completed security assessment. SOC 2 readiness means the controls were prepared for an audit. It is not a claim that SyncABill completed SOC 2 certification.
04 / THE AUDIT
The architecture review found work worth doing.
What is working
- File checks and deduplication before model spend
- Structured extraction followed by deterministic validation
- Controller-owned review rules
- Manual ledger locks and provider idempotency
- Persistent status and audit history
What comes next
- Move integration secrets behind a backend-only boundary
- Give automatic sync the manual path’s safety controls
- Add a labeled invoice evaluation set
- Record model, prompt, cost, and correction data
- Move long-running work to a durable queue
CURRENT STATE
SyncABill is an early production product. Accounting auto-sync is disabled. The current production model is Gemini 3.5 Flash-Lite. A versioned invoice test set remains planned work for measuring model changes and catching regressions.
05 / WHAT I OWNED
From the first workflow to the security review.
I founded the product and own its requirements, architecture, testing, review, failure handling, integrations, and operation. I use coding agents to implement software, then inspect and test what they produce. The product decisions and accepted results remain my responsibility.