Lab · After Send · 5 min read

The payment was sent. Did the supplier process it?

A supplier calls about an invoice marked paid. The status is accurate, and the accounts payable specialist still can’t tell what to do next.

What was hard
“Paid” hides three facts: sent, processed, and matched. A specialist has to read the history to find out which is true.
What I decided
Lead with the two facts that can differ, then who acts next. The history stays, folded underneath.
Why it matters
A specialist who can’t tell has to guess: a follow-up nobody needed, or a second payment on top of a good one.
What I did
The hierarchy, the flow, and the states, then the prototype in code with Claude Code. No findings yet: the test I’d run first is below.

Try the prototype

Independent concept on simulated data. Every name and reference is made up.

The payment flow, simplified

“Paid” appears at step 2. The money moves at step 3.

  1. Supplier

    Sends the invoice

    INV-20483, for $4,860.

  2. Buyer

    Issues a virtual payment

    A one-time card number for the exact amount. The supplier gets a notice.

    The supplier calls here: sent, not processed.

  3. Supplier

    Processes the payment

    Charges the card number before it expires, and the money moves.

  4. Buyer

    Matches it to the invoice

    INV-20483 closes in the books.

From step 2 on, the buyer’s screen says “Paid.”

Try it, it’s live

Scenario
Role
  1. Find it
  2. Interpret it
  3. Follow the handoff
  4. Close the loop
  5. The exception

Larkspur Packaging calls about INV-20483. Open its row to see where it stands.

Wren Payments

Fieldstone FoodsAccounts payable

Simulated: “Process this payment” charges nothing.

A supplier calls, and “paid” turns out to be three different things

Thursday afternoon. Larkspur Packaging calls accounts payable about invoice INV-20483. The specialist opens the payment: sent October 28. So it’s paid.

“Paid” is standing in for three facts, and the screen says one of them.

I think the design problem is the hierarchy: keeping the facts apart, and saying who moves next.

An accounts payable specialist at her laptop with a desk phone to her ear, looking puzzled, with a speech bubble holding a question mark.

“Paid”

  • The buyer sent it. The only fact the status shows.
  • The supplier processed it. Nothing on the screen says.
  • The buyer matched it. Not yet, so the invoice is still open.

Six decisions, and the reason behind each

None of these needed new data. The one I’d highlight: saying who acts next.

  1. Two facts, not one status

    The record opens on “Supplier processing” and “Invoice matching,” each named for who owns it.

    Why: two facts can differ without either one lying.

  2. Say who acts next, with one button

    One line names who moves next: you, the supplier, or no one. Anything to do is one button.

    Why: the specialist’s question is “do I follow up?” A screen that answers it outright beats a log.

  3. Let the invoice reference carry the handoff

    INV-20483 titles the record, heads the supplier’s notice, and is what the match is checked against.

    Why: both sides know the invoice. Neither knows the payment’s own number.

  4. Show the supplier only what the buyer would share

    The notice carries the buyer, the invoice, the amount, and the last good date. Not the approver, the coding, or the notes.

    Why: the handoff crosses two companies.

  5. Keep the history, folded

    Every event stays on the record, under “Activity,” closed by default. Both sides draw from the same list of events, so they can’t disagree.

    Why: the log is the evidence, not the answer. It stays one press away for the day the answer looks wrong.

  6. Words and a shape before a color

    Each status gets a word and a mark. Color comes third.

    Why: a row has to read through a screen reader, and to someone who can’t see red. The word does that on its own.

One invoice reference runs through four screens

Experience architecture

Every screen carries INV-20483.

  1. Buyer

    Payments list

    Search by reference. Status in plain words.

    Where it can fail

    Two invoices from one supplier. The reference tells them apart.

  2. Buyer

    Payment record

    Two facts. Who acts next.

    Where it can fail

    “Delivered” is not “read.” The record says who got it, and can resend.

  3. Processing happens here

    Supplier

    Payment notice

    Process it.

    Where it can fail

    Processed in part. Outside this concept, and the first question for engineering.

  4. Matching happens here

    Buyer

    The same record

    Ready to match. Review and confirm.

    Where it can fail

    The wrong invoice or amount. A mismatch can’t be confirmed.

Status first, history second, and why that order is worth testing

Larkspur is on the phone. Both records hold the same facts. Try answering from each.

v1 · activity first

The record as a log

Payment VP-7Q2M-11
Activity
  1. Payment issued
  2. Notice sent to ar@larkspur.example
  3. Notice delivered
StatusSent Amount$4,860.00 Valid throughNov 27
Has the supplier processed it?
Nothing says. Three events, and no fourth.
What do I tell them?
It’s here, in two places, while they wait.
Do I follow up?
Nothing says. It’s a judgment call every time.

v2 · status first, the working direction

The record as an answer

Larkspur Packaging · INV-20483 · $4,860.00
Supplier processingNot processed yet Invoice matchingNot yet
Who acts next Larkspur Packaging Has until Nov 27. Notice went to ar@larkspur.example. Follow up if it’s still waiting on Nov 20.
Has the supplier processed it?
No, as of Nov 5, 2:05 pm.
What do I tell them?
Notice went to ar@larkspur.example. Good through Nov 27.
Do I follow up?
Not yet. On Nov 20, if it’s still waiting.

Why test it rather than ship it. A stated status is only as good as the event behind it. If a processing event sits in a queue, v2 is confidently wrong where v1 was merely slow. So v2 says when it last checked.

  • The test: half in each order: find the invoice, read its status, say who acts next, and handle the expired one.
  • Measured: correct status readings, time to find the invoice, and any press that would duplicate a payment.
  • Findings: none yet.
5
specialists try both records
3
receivables people walk the notice
2
matched sets of five payments
What it settles
  • If they trust the summary and still open the log when it matters v2 stays.
  • If they read past it to the log anyway v1 was right, and the summary is noise.

Where the concept comes from, and what it doesn’t claim

Three kinds of public product description, and the question each raised.

The screens, events, permissions, and matching here are my assumptions, not any bank’s procedures.

Card program management tools

Where does a payment’s handoff to the supplier become visible?

Virtual payment programs

Can the invoice reference be the one thing both sides search by?

Supplier-charged virtual accounts

In American Express vPayment, a supplier charges a virtual account, then the data is reconciled against the buyer’s details.

Processing and reconciliation are two events there too. Should a buyer see two facts?

A day to build, thirteen years to know which fact to put first

The prototype took a day with Claude Code, on this site’s own tokens. A test script confirms Process and Confirm match can’t be pressed twice.

The agent built what I decided. The decisions came from thirteen years of enterprise workflows.

What this page can’t settle: which events a bank’s systems can promise, what a supplier’s receivables desk does with a notice, and where compliance draws the line.

An agent will build whichever record you ask for. Deciding which fact goes first is still the hard part.