PROFESSIONAL WORK · Finance & review
Invoice automation
Creates accounting invoices from approved timesheets and contract terms, and blocks duplicates when the same event arrives twice.
BuiltProductionDocumented October 15, 2026
My contribution
Designed, built, tested, and operated the invoicing workflow, working with finance on exceptions and corrections.
Tools
Python · Webhooks · QuickBooks Online · PostgreSQL
How it works
- InputApproved timesheetWebhook event from the timesheet system
- StepLoad agreement termsRates, holiday dates, overtime rules
- StepCalculate line itemsRegular, overtime, holiday, on-call, callback, orientation
Unknown holiday allowance → regular/overtime pricing, flagged for review
- CheckDuplicate checkSource-specific identity for each timesheet
Replayed event → blocked
- OutputCreate the invoiceQuickBooks Online
- PersonFinance reviewEach outcome is recorded for exceptions and corrections
Decisions that mattered
Duplicates need business identity
Repeated webhook delivery is expected. Source-specific identity checks prevent a replay from creating another invoice; matching a customer and amount alone can incorrectly block two legitimate invoices.
Agreement terms beat calendar assumptions
Holiday treatment follows the client agreement’s allowed dates. An unknown allowance falls back to regular/overtime pricing and marks the draft for review.
Zero can mean missing context
A zero daily overtime threshold needed a scheduled-shift rule, rather than classifying every hour as overtime. This edge case became an explicit calculation path.
Separate creating from observing
Payment-status checks run on their own read-only path (below), so refreshing a status can never change invoice math or trigger an accounting write.
Results
Between June 13 and October 6, 2026, the workflow created 150 invoices in production (144 active, six cleared) and blocked 185 duplicate triggers across 133 timesheets.
Scope & limits
Financial amounts and customer records are left out. Corrections to agreement rules after launch are part of the production history.
Follow-on: invoice status reconciliation
BuiltProduction-validatedDocumented August 27, 2026
A separate console that tracks where each invoice stands with the vendor (approved, payment initiated, or paid) without collapsing those into one status.
Built the status console and durable reconciliation path, then fed its snapshots into operational reporting.
Tools
Python · Streamlit · PostgreSQL · Vendor APIs
- InputKnown invoice IDsFrom the invoicing workflow
- StepRead vendor statusRead-only: no accounting writes
Missing record (404) → set aside for reconciliation
- StepSave a snapshotRaw status, available timestamps, last-checked time
Paid → no further polling
- OutputConsole & operational chatOne snapshot, used in both places
Unknown timing stays unknown
An invoice can be known to be approved even when the approval timestamp is missing. The system leaves the date blank rather than inventing an approval date or overdue age.
Paid records need less polling
Saving a final paid snapshot stops the console from spending API quota on invoices that are already settled.
Missing isn’t automatically broken
An upstream 404 can mean an invoice hasn’t been uploaded yet or was voided, so it goes to reconciliation instead of being treated as a failed create.
A full production validation on August 27, 2026 attempted 88 reads, refreshed 76 snapshots, and set aside 12 missing-record responses, with zero accounting writes. As of the October 6 checkpoint, the stored snapshot still dated from August 27; recurring runs weren’t confirmed.