Independent backend builder

Paper-to-Digital Invoice Intelligence Platform

Built a CDK-defined serverless invoice workflow: Step Functions coordinates Textract and Lambda, Amazon Bedrock suggests missing or low-confidence fields, and Streamlit verifies uncertain values before PostgreSQL persistence.

Browse source

Role: Independent backend builder
Year: Jul–Sep 2025 · Updated Oct 2026
Scope: Python, PostgreSQL, Lambda, Step Functions, S3, Textract, Amazon Bedrock, Streamlit, Google OAuth/OIDC
Evidence: Implementation added October 2026; local tests, cloud validation pending

Problem + constraints

Invoice OCR can miss fields or assign low confidence. Unverified values need review before they become database records.

Locally tested implementation; AWS execution and database integration still require deployment validation.
Current AnalyzeExpense path is synchronous and supports single-page PDFs and supported images; multi-page asynchronous processing is not implemented.
Initial project: July–September 2025. Further development in October 2026 added Step Functions orchestration, human review and Bedrock fallback.

Contribution boundary

My contribution

Added Google OAuth/OIDC sign-in with verified-email allowlisting, explicit user-ID attribution and authorization checks before every portal data page. Live callback testing awaits owner configuration.
Built a serverless invoice pipeline with AWS CDK and Step Functions coordinating Textract extraction and Lambda processing.
Added a Streamlit review screen that keeps uncertain extractions out of PostgreSQL until a reviewer validates them.
Added Amazon Bedrock fallback extraction for missing or low-confidence fields using the existing invoice schema.

Outside my claim

Production adoption, uptime, accuracy or latency guarantees.
Retrospective proof that newly added features existed during the project dates.

System design, explained

The 30-second explanation

Think of this as an invoice intake desk. A document arrives, a reader finds the important fields, and a second reader suggests anything uncertain. A person checks those suggestions before they enter the accounting database. Clear, complete extractions can take the direct route.

Implementation statusLocally tested implementation with Google OAuth/OIDC reviewer sign-in. Google client configuration, live sign-in, AWS deployment and provider validation remain pending; the current path accepts single-page PDFs and supported images.

Follow the data

A map of the moving parts.

Select any stage to inspect its input, work, output and failure behavior.

Example, not a live resultIllustrative invoice: INV-1042 from Cedar Supply, dated 2026-10-01, total $240.00. Suppose the total is difficult to read.

00 / Verify the reviewer

Google confirms identity; the portal separately decides who may access invoices.

Approved, unexpired identity → portal upload and review pages

01 / Read the document

A versioned source becomes an extraction artifact. The workflow passes references, not the whole document.

Extraction artifact → confidence decision in lane 02

02 / Decide what needs a person

The fallback stage calls the model only for missing or low-confidence fields.

Confidence gate · two possible routes

Both routes reach PostgreSQL only after field validation. Review waits for explicit human approval.

Technology, with a purpose

What each tool is responsible for.

Languages, frameworks and services play different roles. Here is why each belongs in this system.

Technology roles and design rationale
Technology	Responsibility	Why this choice
Google OAuth / OIDCReviewer identity	Authenticates Google accounts; a server-side allowlist controls portal access.	Avoids a shared application password while preserving explicit access and audit mapping.
PythonLanguage	Normalization, validation, workflow handlers and persistence.	One language connects OCR results, business rules and database writes.
Amazon S3Object storage	Originals, extraction artifacts and pending review records.	Keeps documents and unapproved candidates separate from accounting rows.
AWS LambdaCompute	Starts workflows and runs individual processing stages.	Each stage runs on an event without a continuously running application server.
AWS Step FunctionsOrchestration	Sequences stages and branches at the review gate.	Makes the workflow and failure transitions explicit.
Amazon TextractDocument extraction	AnalyzeExpense supplies fields, OCR text and confidence.	Provides invoice-aware extraction before using a general language model.
Amazon BedrockModel service	Converse suggests missing or uncertain values from OCR text.	Adds a bounded fallback while keeping suggestions reviewable.
StreamlitReview interface	Displays candidates, originals and editable fields.	Makes an internal Python review workflow practical without a separate frontend.
PostgreSQLRelational database	Stores normalized, validated invoice records.	Typed fields, constraints and unique extraction IDs support reliable writes.
AWS CDKInfrastructure as code	Defines the bucket, functions, workflow and permissions.	Makes the infrastructure reproducible and reviewable alongside application code.
Secrets Manager + IAMAccess control	Supplies the database secret to persistence and scopes AWS access.	Keeps database credentials out of source code and limits service permissions.

Interview walkthrough

How I explain the design.

Start with the problem, follow one input, then explain the tradeoff.

01
I start with the trust boundary: uploading a document is not the same as accepting its values.
02
S3 triggers a Step Functions workflow. Textract reads it; Python normalizes the fields; Bedrock only fills uncertain gaps.
03
The confidence gate has two exits. Complete, confident fields can save directly. Every model suggestion goes through Streamlit review.
04
I use a unique extraction ID to prevent duplicate saves. The next validation step is a deployed end-to-end run with representative documents.

Decisions + tradeoffs

D-01

Hold uncertain records outside PostgreSQL

Private S3 stores extraction candidates; the review gate writes only verified fields into the invoice table.

D-02

Keep model suggestions reviewable

Bedrock recovers requested fields from OCR text without replacing high-confidence values. Model-derived fields always require review.

D-03

Use an isolated CDK stack

The intelligence stack defines S3, Lambda, Step Functions and scoped permissions. Existing PostgreSQL and its secret are deployment inputs.

Evidence ledger

Claims are labeled by what a reader can inspect now. Withheld items include the measurement needed before publication.

E-01

Implementation and local verification

Limited

New implementation and focused tests were added in October 2026. Deployment and live provider validation remain pending.

Method: Local domain, orchestration and API checks; provider responses are mocked.
Source / path: Repository implementation and test files

E-02

Deployment and measured outcomes

Withheld

No new cloud deployment, production benchmark or coverage measurement is claimed.

Method: Verify deployed services and publish dated measurement artifacts before adding outcome claims.
Source / path: Explicit verification boundary

Not production-ready

Current limits

Locally tested implementation; AWS execution and database integration still require deployment validation.
Current AnalyzeExpense path is synchronous and supports single-page PDFs and supported images; multi-page asynchronous processing is not implemented.
Initial project: July–September 2025. Further development in October 2026 added Step Functions orchestration, human review and Bedrock fallback.

Redesign for scale

Run deployed integration checks with representative inputs and record dated results.
Monitor failures, retries and operating costs with a defined ownership process.