A purchase order arrived, but payment has not

A purchase order is the buyer's record, not yours

The document that arrived describes what the buyer's organization asked for: items, quantities, prices, perhaps a requested delivery date, and a reference their accounts team will recognize. What it does not contain is your answer. Nothing about receiving a purchase order shows that your business accepted it, that any payment has been made, or that credit has been approved. Before anything moves, record the PO as its own dated event — what arrived, from whom, and which version — so the later steps can be measured against it rather than blended into it.

This separation matters because the release decision sits somewhere downstream. If the team treats the PO's arrival as the finish line, every later record — the order you create, the invoice you send, the payment you verify — collapses into one assumption. Keep them as four distinct events and the decision becomes answerable from records instead of habit.

Name the condition that releases the goods

Before the order reaches fulfillment, identify which documented condition allows release. The usual candidates are verified receipt of funds, an accepted credit arrangement carrying stated payment terms, or a documented due-on-fulfillment arrangement. Shopify's B2B documentation, for example, describes payment terms assigned to company locations and draft orders, with documented options such as net periods, due on fulfillment, and fixed dates on drafts. Those are configurable commercial terms in that platform — they describe when payment is expected, not whether it has arrived, and they say nothing about any other platform.

If your records name no condition, the release decision has not been made; it has merely not yet been questioned. Write the condition down together with the document it comes from. Where an internal habit such as 'we ship on PO' conflicts with a stated term such as a net period from invoice, keep both visible and resolve the conflict before describing either one as policy.

Walk the four records in order

Take the events in sequence and stop at the first unsupported link. First, the PO itself: date, version, references, and whether a later amendment replaced part of it. Second, your acceptance: the order or acknowledgment your business actually created. In Shopify, a merchant can create a draft order and send an invoice with a checkout link, and a paid draft becomes a regular order. Drafting and recording a payment are distinct acts, so the existence of your order record says nothing about money.

Third, the payment request. Shopify's draft-invoice guidance notes that draft invoices carry a checkout link and can be reviewed before sending, and it cautions against marking an order paid before payment is received. The same documentation notes that adding an item after invoice creation does not automatically recalculate shipping rates, so a changed order needs a fresh check before the invoice is treated as accurate. Fourth, funds verification: the provider or bank record an authorized person actually opens and reads.

One more trap sits at the end of the chain: a payment term's expiry does not collect anything. Shopify's payment-terms documentation states that expiry of a payment term does not itself automatically capture payment. A passed due date is a fact about the calendar, not a fact about your balance.

Unresolved links have owners, not defaults

When the chain stops early — no acceptance, no invoice, no verified funds — name the role that decides what happens next. Credit approval belongs to whoever owns credit decisions in your business. The meaning of a payment status belongs to the provider whose record carries it. Whether a PO's printed terms create enforceable obligations is a question for qualified counsel, not for this workflow.

If the sticking point is how the store itself represents these states — a checkout screen that looks paid while the provider record disagrees, or a draft-order flow the team does not fully understand — that storefront question can be brought to a Prism consultation. Scope, responsibilities, fees and terms are confirmed before any work begins.

Release-condition worksheet

Complete one copy per order from your actual records. The worksheet names the documented condition for release; it does not manufacture one. Where a record is missing, write that it is missing rather than treating the next step as covered.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.