One purchase order is being used for several store orders

The same number on every order proves only that someone typed it

When several store orders cite one purchase order, the repetition is a reference, not a tally. In Shopify's B2B flow, buyers select an associated company location and can add a purchase-order number at checkout, and an order submitted with payment terms can sit with payment pending. That cited workflow records what the buyer entered; it does not itself establish that the entry was checked against the buyer's authorization, the PO's remaining balance, or your credit decision. Whether your store has any other installed control that totals or validates draws is a question about your actual configuration — inspect it rather than assume it exists or does not exist.

So the question 'does this new order fit within the PO' cannot be answered from any single order screen. It needs a register the merchant maintains: the buyer's document on one side, every accepted draw on the other, and a running remainder between them.

Build the register from the PO's own scope

Start with what the buyer's document actually covers. Some purchase orders state per-line quantities, totals, or explicit caps; others do not. Oracle's procurement documentation for blanket purchase agreement lines — a version-specific operational model, not a universal rule — describes lines that identify goods or services without individual delivery quantities, dates, and amounts, while still carrying item descriptions, prices, and buyer and supplier item attributes. Where a PO is written that way, the document itself will never announce that it is exhausted. Your register has to do that work.

Record each line's scope: the items covered, the prices, any stated totals, caps or expiry, and the buyer contact authorized to confirm releases. Where the PO states no cap, write 'unspecified' in the register. An absent limit is a missing fact, not evidence of an unlimited one.

Reconcile the draws before the next one is accepted

Take the steps in order. List every store order referencing the PO, with its date, items, quantities, and value. Remove a draw from the committed sum only when the cancellation or reversal is documented and the buyer's PO treatment of that draw is confirmed — a refund status on its own does not show that the goods or obligations were unwound, and dropping a draw on that basis alone can understate committed PO usage. Keep partially shipped or partially paid orders at their actual state. Sum committed quantities per line and committed value overall, then compare those sums against whatever the PO documents. The remainder — documented total minus committed draws — is the only figure that answers whether another release fits.

Keep payment state beside the arithmetic, not inside it. A draw can be unpaid and still consume the PO's quantity, and a paid draw can still have exceeded it. Because orders on payment terms can have payment pending, the register should show which committed draws are also uncollected; that is credit exposure wearing the same reference number, and it belongs in the release conversation.

An exhausted or silent PO needs a named decision

When the register says the remainder cannot cover a new draw, or says nothing because the PO never stated a total, the decision is not fulfillment's to make. Name the owner who may accept an overdraw or accept against an unspecified PO, and record what buyer confirmation was required and what was actually received. A buyer's written release reference for the new draw is evidence; the checkout's PO field is not.

If repeated draws against one PO are colliding with the way the store's B2B checkout or draft-order flow records them, that storefront question can be raised in a Prism consultation. Scope, responsibilities, fees and terms are agreed before work begins.

PO draw register

Maintain one register per buyer purchase order and update it before each new release is accepted. Record what documents actually show; where the PO is silent, say so rather than inferring capacity. Keep the filled register internal.

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.