Source before summary
Original emails and files remain intact and linked.
Technical proposal · 2026 Built for long-term iteration
Purchase orders in.
Clean operational data out.
A controlled Google Workspace workflow that receives buyer POs and supporting files, organizes them in Shared Drive, extracts structured data with AI, validates what matters, and keeps the master Sheet current.
Google Apps Scriptn8nClaude APIShared DriveGoogle Sheets
01 / Understanding
This is not a document-filing task. It is an exception-handling system.
The happy path is easy: read a clean PDF and write values to cells. The real work is handling buyer variation without corrupting the tracker or losing the original context.
I would design the workflow around provenance, repeatability, and human review. Each tracker row should answer three questions: where did this value come from, which checks passed, and what happens when the document does not match expectations?
Schema before prompting
The tracker defines the extraction contract.
Review before guessing
Ambiguous values are flagged, never invented.
02 / Architecture
Explore the proposed processing chain.
Select a stage to see its responsibility, safeguards, and output.
01
Selected stage
Capture
Monitor only the agreed mailbox, labels, or aliases. Capture the message, buyer identity, timestamps, and every supported attachment without disturbing the original email.
Controls
- Idempotency key
- Sender allowlist
- Thread trace
OutputNormalized intake event
03 / Real documents
One workflow. Different paths for different evidence.
Buyer documents will vary. The system should adapt deliberately, not hide that variation inside one oversized prompt.
Standard path
Text-based PDF with clear line-item tables
Extract embedded text and tables, map values to the canonical PO schema, reconcile header totals against line items, then write the approved record to the tracker.
01PDF parse
02Claude schema
03Math check
04Auto-sync
Human review ruleOnly if a required field is absent or contradictory
04 / Delivery
A pilot first. Production hardening after evidence.
Indicative windows are refined after the sample review. The engagement can then continue as a 3–6 month build-and-improve cycle.
Define the data contract before automating the inbox.
Review anonymized samples, the current tracker, buyer-specific conventions, Shared Drive rules, and Workspace constraints. Convert that knowledge into a field dictionary and an explicit exception policy.
Outputs
Sample document inventory
Canonical PO JSON schema
Folder and permission map
Pilot acceptance criteria
05 / What gets delivered
Source code, operational controls, and a system your team can own.
Apps Script layer
Gmail and Drive intake, triggers, config, Sheet utilities, safe retries, and quota-aware batching.
n8n workflows
Importable, modular flows for orchestration, branching, model calls, alerts, replay, and maintenance.
AI extraction contract
Versioned prompts, JSON schemas, buyer rules, null policy, confidence signals, and test fixtures.
Shared Drive design
Folder naming rules, Google Group permission matrix, service-account access, and document linking.
Master tracker
Validated upserts, processing states, source links, review queue, error log, and operational views.
Documentation
Architecture map, setup guide, field dictionary, runbook, change log, and recorded handover walkthrough.
Definition of done
Acceptance is based on observable behavior, not “the automation ran.”
IntakeThe same email cannot create a duplicate PO on retry.
FilesEvery tracker record links to the original email and document pack.
ExtractionRequired fields conform to the agreed schema or return an explicit null.
ValidationConflicts and low-confidence fields enter a visible review state.
RecoveryFailed runs can be diagnosed and replayed without manual reconstruction.
OwnershipThe team receives source, credentials map, documentation, and handover.
06 / Reliability
The controls that keep “AI-powered” from becoming AI-fragile.
The automation should fail visibly, preserve evidence, and be safe to rerun. That is the difference between a demo and an operating system.
R1Buyer format drift
Regression set by buyer
New layouts are tested against stored anonymized samples before prompt or schema changes go live.
R2Model hallucination
Nulls, citations, confidence
The model must return missing values as null and identify where extracted values came from.
R3Duplicate processing
Deterministic idempotency
Message IDs, file hashes, and PO keys prevent retries from creating duplicate folders or rows.
R4Apps Script quotas
Batch and offload
Short Apps Script actions handle Workspace events; heavier orchestration and retries stay in n8n.
R5Concurrent Sheet writes
Queue and lock
Atomic upserts and locking protect rows when several POs arrive or a replay is running.
R6Permission sprawl
Groups and least privilege
Access is assigned through Google Groups with a documented service identity and minimal scopes.
07 / Relevant proof
Comparable LLM extraction work, without pretending the inputs are clean.
The closest relevant implementation used a different low-code stack, but solved the same core engineering problem: unstructured evidence into trusted operational records.
Comparable implementation
AI-assisted VIN extraction inside a field operations and invoicing system
Field users captured VIN images. An LLM vision API extracted the identifier into a structured record; unreadable images returned an explicit no-result state; duplicate VINs were isolated; and validated data fed installation logs, compensation, and dealership invoicing.
Direct relevance
Document capture · comparable LLM API · structured extraction · validation · duplicate handling · downstream operations
01CaptureField image
02ExtractLLM vision
03ValidateNo-result + duplicate rules
04OperateLogs, payouts, invoices
Apps Script automation experience
Scheduled Drive organization and file-routing automations, with the same emphasis on predictable folders, triggers, and maintainable configuration.
Model-agnostic extraction design
Claude is the proposed primary parser. The schema, validation layer, and tests stay separate so Gemini or another comparable model can be evaluated without rebuilding the workflow.
Async-friendly and maintainable
Short written updates, versioned changes, explicit decisions, and owner-facing documentation support a less-than-30-hour weekly engagement.
08 / Illustrative capacity
Estimate the manual processing time the workflow could redirect.
This is a planning model, not a performance guarantee. It assumes three minutes of human review per PO after automation.
Illustrative time redirected18hours / week
Low-risk first step
Start with a sample-document pilot.
Provide anonymized buyer documents and a copy of the tracker. The first output is a field schema, exception map, proposed architecture, and pilot acceptance criteria before the production workflow is touched.
01
10–20 anonymized PO emails with attachments
02
A copy of the current master tracker
03
Required fields and buyer-specific rules
04
Proposed Shared Drive folder structure
05
Workspace admin and permission constraints
09 / Practical questions
Decisions to settle during discovery.
These do not block a first conversation. They define the pilot and prevent risky assumptions later.
01Which mailbox or labels define an incoming PO?
Confirm aliases, forwarding rules, historical threads, sender exceptions, and whether replies or revisions should be reprocessed.
02Which fields are authoritative in each document type?
A techpack and PO may disagree. The field dictionary should state which source wins and when a person must decide.
03What error rate is acceptable for auto-sync?
High-risk commercial fields may need stricter confidence and validation rules than descriptive fields.
04Who should see each buyer folder?
Map buyers, internal teams, service identities, and Google Groups before automation creates or shares production folders.
05How should PO revisions be represented?
Decide whether revisions update one record, create versions, or create a new line while preserving the earlier state.