Recipients

To: the buyer's configured Phase-1 alias — typically procurement@, ops@, or warehouse@ for buyers with a separate procurement function; finance@ for smaller buyers where finance handles both delivery confirmation and payment. The right alias is captured on the buyer profile when the supplier first invoices that buyer. Cc: the named contact at the buyer who handles the supplier's account (procurement manager, ops manager, or finance lead — same configurable field), plus the financing partner. Bcc: internal Terracore audit alias.

Per-buyer routing — why we configure rather than hard-code

Buyer organisations vary. A multinational like Bokku has a procurement department that signs for goods independently of finance; a smaller supplier's customer might have one accountant who does both. Asking the wrong team blocks the deal. We capture the right alias once, at first-invoice setup, and use it for every subsequent invoice from this supplier to this buyer.

Why the email mentions the upcoming finance email

So the Phase-1 team isn't surprised when finance gets an unrelated invoice email later. (For finance-led buyers where Phase 1 and Phase 2 land in the same inbox, we instead reference the prior thread by message-ID so it threads correctly.) Reduces internal confusion at the buyer.

Speed budget ≤ 5s

From supplier's "Accept terms" tap to email landing in the buyer's Phase-1 inbox.

This is a Meta-approved template

tc_buyer_procurement_nudge — pre-approved with named placeholders for the procurement manager, supplier, items, and amount. Sent in parallel with the B1 email, not after — so the manager gets the WhatsApp at the same time their inbox lights up.

Three buttons, deliberately

Yes, confirm here = fast path, advances to B3 immediately. I'll reply on email = manager acknowledges they saw it but wants to do the formal version; bot replies "Got it — we'll wait for the email." and pauses the WA flow. Wrong contact / dispute = escalation; freezes the invoice and routes to ops.

Why we name the email channel inside this WA message

The procurement manager should know the formal record exists at procurement@bokku.ng — gives them confidence to act fast on WA. If the manager has been replaced and someone else now handles the Prime Goods account, the email is the durable record that survives WA contact churn.

Speed budget ≤ 30s after supplier accepts terms

Vision cross-check

The waybill image is sent through a vision pass that must match buyer name (Bokku), invoice number (INV-23), and item lines against the originally-submitted invoice. Mismatch → manual review queue, not auto-progress. This is where most fraud is caught.

Email path equivalent

If the procurement manager took the email path instead, they'd reply "Confirmed — INV-23" with the waybill PDF attached. We'd parse the inbound email's attachment through the same vision pass. The state-machine outcome is identical.

Why the waybill is non-negotiable

The yes-button alone is too easy to game. Photo + identity-bound corporate email (verified at B4) raises forgery cost meaningfully.

Why OTP to corporate email, not personal

Phone numbers are SIM-swappable. Personal emails (Gmail, Yahoo) can be opened by anyone. The OTP goes only to @bokku.ng — Bokku's verified domain captured at supplier onboarding. If the manager's company email isn't on file, the bot escalates to ops instead of accepting the confirmation.

Speed budget ≤ 5 min

The OTP expires in 5 minutes. If the manager misses it, we re-send once on tap, then escalate to a human at procurement@bokku.ng via the email thread.

Email-path equivalent

If the manager is using the email path, the OTP step is implicit — replying from j.okeke@bokku.ng with a DKIM-signed message is itself the identity proof. We don't ask for a separate code on that path.

Two things happen here in parallel

(1) WhatsApp: the procurement manager gets the confirmation acknowledgement above; their session closes 24h later. (2) Email: a formal closing email is sent to procurement@bokku.ng with the manager's confirmation timestamp, the waybill image, the OTP-verified identity, and the funding-disbursement reference — for Bokku's procurement records.

Phase 1 → Phase 2 handoff

Immediately after this screen, the financier receives F2 (manual decision) and — once they tap "Approve & fund" and complete the F3 wallet instruction — the state machine fires FUNDED and Phase 2's B6 email goes to finance@bokku.ng with the payment instructions. Procurement and finance are kept on separate threads — they have separate jobs.

Session ends

The procurement manager's WhatsApp record on this invoice is closed. They won't receive further messages unless a fraud review or dispute re-opens it.

Trigger

Fired the moment FUNDED state is reached — same parallel fan-out as the supplier's WhatsApp confirmation (S6) and the financier's WhatsApp receipt (F3), but routed to Bokku's corporate finance inbox.

Recipients

To: Bokku's finance-department alias finance@bokku.ng — captured at invoice submission. Cc: Wema Capital (financing partner) plus an internal audit@terracore.ng alias on Bcc.

Why finance, not procurement, on this email

Procurement signed for the goods (Phase 1, B1). Finance / AP is the team that actually processes payments. Asking the wrong team would either delay payment or create internal Bokku confusion about who's paying who.

Money-control assertion

The renderer reads the bank block from payment_instruction.account_owner and refuses to send unless it equals FINANCIER. The supplier's bank account never appears.

Speed budget ≤ 5s

From FUNDED event to delivery in Bokku finance's inbox.

Three places the reference is repeated

In the subject, in the bank-details card, and in the warning block. AP teams skim — repetition prevents missed-reference reconciliation breaks.

Reminder cadence

T-3, T-1, T+0 (morning of due date). Past due date: T+1 (with subject prefix "OVERDUE"), then T+3 (escalation alert to financing partner), then ops phone call at T+5.

Same reference, every email

Reference TC-INV-23-A4F is invariant for an invoice. AP teams sometimes pay against an old reminder — same reference still reconciles.

Tone is friendly, not collection-style

Bokku is a customer relationship. Aggressive collection language risks the relationship. We keep reminders professional and offer scheduling. Real escalation happens off-band, between Terracore ops and Bokku AP.

Speed budget ≤ 30s

Sent at 09:00 WAT exactly via cron. Variance acceptable up to 5min — finance teams check inbox at start of business.

Trigger

Financier-wallet inbound webhook with reference TC-INV-23-A4F and amount within tolerance (MONEY_TOLERANCE = 0.005). Same event drives the parallel S7 supplier WhatsApp + F4 financier WhatsApp.

Money-control assertion

This email is never sent on a buyer reply alone (e.g., "we paid"). The trigger is the wallet webhook with matching reference. If the inbound payment has no reference or a wrong amount, this email is replaced by an "unmatched payment" recovery email (see error flow E2 in System view).

Receipt PDF

Generated server-side in ~200ms — signed, contains Terracore's tax ID, the reference, the inbound bank's identifier, and the timestamp. Suitable as evidence in any payment dispute or audit.

Speed budget ≤ 10s from wallet webhook