Vendor Lifecycle: Coordination → Job Done → Paid

1. The arc

Coordination is the beginning. Job done is the middle. Payment is the end. One job, one thread, no re-typing. That is the whole product thesis for vendors: a PM should never have to re-key a job into a second system because it moved from "we booked it" to "they finished it" to "we owe them $1,038.61".

What we found, in one paragraph

Camellia's mailbox already carries the entire back half of the lifecycle in structured, parseable form — 443 vendor emails, 220 PDF attachments, 44 unique invoices, $39,583.61. The classifier already reads those emails; it just throws them away. The PDF parser that would extract the amounts already runs in the production inbound-email Lambda. The UI stepper that would display the lifecycle is already mounted on the work-order page. Almost none of this is a build — it is wiring, plus one policy decision about which vendor senders we trust.

2. What Camellia's 2026 mail actually contains

Window: 2026-01-01 → 2026-07-29. Sources: production DynamoDB (read-only) plus the live Camellia mailbox via the app's production Microsoft Graph integration (Mail.Read only). Every dollar figure below was extracted literally from downloaded PDF text — none inferred, none estimated.

Categories in the mail stream

Spend by vendor — 2026 YTD, unique invoices only

Spend by month

* July is partial (through 07-29). June is inflated by a single property-level job: MTech invoice 158334-1, $8,387.00 — "Replace Meter Pit Valves".

Proof: 12 real invoices parsed end to end

Fields extracted mechanically from downloaded PDF text — no manual entry, no guessing. Amount evidence strings are stored per row (e.g. PDF JORDAN PERLMUTTER & CO 162425.pdf: Total 1,616.00).

Attribution: how much of the spend attaches to a job

The one attributed invoice is MTech 165501, unit 422, against turnover turnover_d188d1f2… (opened 2026-07-08). Everything else is either recurring contract spend with no job reference, or carries a purchase-order number we cannot resolve — which is the headline finding.

Other gaps worth knowing before anyone builds on this

• DDB email coverage starts 2026-03-17. The EmailIngestion log has no rows before that date. Jan 1 – Mar 16 in this report came from Graph, not from our data. The mailbox itself goes back to 2017-12-07.
• Bodies and attachments are not durably ours on the Graph path. Graph-ingested mail stores metadata only; bodies are lazily re-fetched from Microsoft; every saveIngestion(...) writes attachments: []. Of 2,513 Camellia EmailIngestion rows, only 31 carry attachment metadata — all from the legacy SES era.
• No AppFolio cost data in DDB. 27 Camellia work orders carry appfolioEnrichment; invoices, billableItems, laborItems, estimates are empty on every one. Turnover.totalActualCost is null on all 26 Camellia turnovers. There is no actual-cost figure anywhere in our data model today.
• No Camellia vendor voice records. 528 Camellia voice conversations in 2026, zero VendorCallSession rows — all 56 table-wide rows belong to the Willows test property. All Camellia job-done signal arrives by SMS (7) or is typed into a work order (4).
• "Preferred vendor" is not a modelled concept. VendorMembership for org_jpco holds all 816 AppFolio vendors with no preference flag, and VendorCompany rows store no email address and no phone. The vendor list in this report was derived empirically from mail traffic and fuzzy-matched back to the roster.
• De-duplication is material. Three invoices were re-mailed within 2026 (TK 6000845175, AGD 95048, Royal Textile 251742) worth $2,696.39. Dedupe on (vendor, invoiceNumber, amount).

3. Detection architecture

3a. The signal ladder

3b. Parser lanes and cost

There is nothing to rebuild. PropFlow already has a production multi-strategy PDF→JSON parser whose extraction prompt is literally titled "You are a vendor invoice/quote parser", and both of its legs already execute inside the production inbound-email Lambda — pdf-parse (pure JS, bundled, no layer) for text-layer documents and native Claude PDF document blocks for scanned ones. The only local-only piece is an optional free Ollama pre-pass, which must be bypassed in Lambda rather than merely allowed to fail.

Blended per-invoice metered cost at 70% text-layer / 30% scanned: $0.0029 all-Haiku, $0.0059 Haiku-text + Sonnet-scanned, $0.0087 all-Sonnet. At an estimated 60 invoices/month that is $0.17–$0.52/month; a full ~700-document 2026 backfill batched is $1–$3 one-time. The approval ask for lane (b) is well under a dollar a month — so the model should be chosen on accuracy, not price.

Volume of 40–80 invoices/month (midpoint 60) is the one soft number here — it is an estimate, not a measurement. The 44 unique invoices this mining pass found are Camellia only, one property. Count the real s3://propflow-photos/email-attachments/ prefix before quoting the cost figure onward.

3c. What ships dormant vs. what runs as backfill

• Runs now (lane a): a guarded --property-id-scoped, dry-run-default backfill script that reads PDFs, extracts, and writes only detection records (PK=PROP#<id>, SK=INV#<id>). Never touches accounting, AppFolio, or any live saga.
• Ships dormant (lane b): the inbound-email hook, behind INVOICE_DETECTION_ENABLED defaulting false — reviewed once in the same PR rather than written twice. Keep the parser import dynamic; the existing dynamic-import block exists specifically so heavy parser trees don't deserialize on every inbound email.
• One shared extraction module, two lanes. Do not fork the prompt or the strategy ladder per lane — that drift is what previously let a fix sit dead for a release.

3d. Per-vendor format profiles (the parser spec, summarized)

4. UI placement options

Almost nothing new needs to be invented. The app already has a shared progress rail driven by a pure server-side step derivation, a vendor-invoice rollup page, a dashboard stat-card grammar, and a registered mtdVendorSpend metric. All four mockups below are extensions of one of those.

Why it's S: two entries in WoProgressStepKey, two in LABELS, two in doneFlags, and three new fields on the derivation input. UI diff: zero — toStepperSteps maps state 1:1 already. The one thing to eyeball is eight horizontal steps on a phone; the rail already wraps in overflow-x-auto and supports vertical orientation.

Why it's S: one ClickableStatCard inserted into an existing group plus a grid-class change — roughly ten lines. The card doubles as the honest scoreboard for the attribution gap: today it reads 0.7%, and it is the number PO sync is supposed to move.

Why it's S: a header total beside the existing percent counter and a per-row amount opposite the existing "View work order →" link. No new component. Em-dash for unknowns — never fabricate a number.

Why it's M, not S: not design — the work-order list fetches ?view=meta (scalars only), so the new field has to be added to the meta projection, and the mobile card renderer must move in lockstep with the column array. Estimated figures in the turnover mock are illustrative; only the invoiced column carries mined values.

5. Effort ladder and decisions needed

Decisions needed from Fede

1. Trusted-sender gate policy for vendor attachments. The inbound path currently hard-rejects an untrusted sender carrying a data attachment. Random vendors will not be on the trusted-data-sender list, so as written, slice 3 rejects almost every real invoice at the gate. Decide whether vendor invoices get their own sender-trust rule (e.g. trust follows the PM-confirmed vendor domain from slice 0) or whether the gate stays absolute. This is the likeliest blocker to a working end-to-end demo.
2. Enable purchase-order sync for Camellia. Unblocks slice 4 and converts $6,688.09 of already-collected 2026 spend — plus every future MTech, Home Depot, and Royal Textile invoice — into hard attribution. Nothing else in the ladder moves the 0.7% attribution number nearly as far.
3. Preferred-vendor domain confirmations. There is no preferred-vendor concept: org_jpco's membership list is all 816 AppFolio vendors with no flag, and the nine-vendor list in this brief was derived empirically from mail traffic by fuzzy name/domain match. Slice 0 needs a PM confirm screen — "is brenda@americangaragedoor.net American Garage Door?" — to turn that fuzzy match into a fact. Decide whether that screen is a one-time backfill sweep or an ongoing inbox affordance.
4. Metered-spend approval for the Lambda lane. Until that approval lands, extraction runs subscription-only (lane a) and the inbound-email hook ships dormant behind an off-by-default flag. The ask is small — $0.003–$0.009 per invoice, well under $1/month at Camellia volume, with a one-time backfill of $1–$3 — but it is a real gate: AWS_LAMBDA_FUNCTION_NAME forces the metered credential and there is deliberately no force-bearer override, so "Lambda on the subscription" is not an option.