Payment controls and records

A requisition was mistaken for a confirmed order

Do not reserve stock until the records show which event you actually hold: a requisition or request, the buyer's internal approval, an issued purchase order, your store order, or a payment reference. Oracle's iProcurement documentation treats requisition approval as a workflow stage with its own notifications and treats creation and approval of the resulting purchase order or agreement as separate events. Shopify separately lets a merchant draft an order and send an invoice, while a paid draft becomes a regular order and recording payment is distinct from drafting. Keep those five references in separate fields, then reserve only under your written release rule. If the accepted-order record is absent, the finding is request or approval received, order not confirmed.

For: Authorized staff of a research-only merchant deciding whether an institutional purchasing message permits them to reserve stock.

Updated 2026-10-01

Get help with checkout

Name the procurement event before touching inventory

Start with the exact artifact that arrived: an emailed requisition, a portal notification, a purchase-order PDF, a checkout submission, or a remittance message. Write the buyer organization, the sender role, the identifier on the artifact, the date, and the products or quantities it mentions. Do not convert the artifact into an order because it sounds urgent or because the buyer has purchased before.

The decision for this page is narrower than fulfillment. You are deciding whether the event is a request for supply, an internal buyer decision, an issued commercial commitment, your own order record, or money movement. A requisition can be real and still not be an order your store accepted. Oracle's older iProcurement guide is useful only for that distinction: approval of a requisition is one stage, and a resulting purchase order or agreement is created and approved separately. It is not a current interface guide and not a legal test of purchasing authority.

If the artifact is ambiguous, label it by the strongest fact it proves. A forwarded approval screenshot proves that someone saw an approval screen; it does not prove the PO was issued to you. A buyer saying 'approved' in a message proves the word was used; it does not prove which limit, entity, or order document was approved.

Keep requisition, approval, PO, order and payment references apart

Use separate fields for the requisition number, the approval reference or approver role, the issued PO number, your store order number, the invoice or draft reference, and the payment transaction reference. A field that contains 'PO maybe pending' is not a PO number. A payment reference answers settlement questions; it does not create the buyer's authority to purchase.

Shopify's draft-order flow shows why sequence matters. A merchant can create a draft order and send an invoice with a checkout link, and a paid draft becomes a regular order. Drafting is not payment, sending is not acceptance by the buyer's procurement process, and payment recording is distinct from the draft. Treat a Shopify draft as your commercial draft until the record shows it became a regular order or was otherwise accepted under your terms.

When the buyer uses a portal or procurement suite, ask which reference their system considers the commitment to buy. The portal's approval notice may describe an internal stage. The issued PO or agreement, the storefront order, and the supplier invoice are different records even when the amounts match.

Investigate in an order that preserves the evidence

First, preserve the original message or portal export without editing identifiers. Second, record the buyer's stated purchasing route, including whether they require a PO, a supplier portal submission, or a checkout link. Third, open your store record and write whether a draft, regular order, invoice, payment, or none exists. Fourth, compare quantities, entity name, and totals across only the records that exist. Fifth, decide whether stock may be reserved under the written release rule.

Do not fill gaps by inference. If the buyer has an approval but no issued PO, the gap belongs to the buyer's purchasing owner. If the buyer issued a PO but your store has no order, the gap belongs to the person who converts institutional POs into store orders. If your store has an order but no release under your rule, the gap belongs to your internal release owner. Name that owner rather than letting the stock team guess.

A reservation made early is an operational decision, not evidence that the order existed. If you choose to hold stock while authority is unconfirmed, record that as a provisional hold with an expiry and owner, not as fulfillment.

Decide unresolved authority and scope outside this page

The buyer's purchasing owner decides whether a requisition became an issued PO and whether the person requesting stock had authority. Your sales or operations owner decides whether your store accepts the order and which status releases inventory. Your finance owner decides whether any received payment is matched and whether an invoice should be issued. A platform status cannot replace those decisions.

Legal questions about contract formation, public procurement rules, credit terms, tax treatment, or whether a research-only label permits a sale are outside this administrative workflow and should go to qualified review with the preserved records. Product suitability and provider eligibility are also separate questions.

If the recurring problem is that purchasing messages become stock holds before the store record is clear, describe that checkout or order-intake concern to Prism with the platform and a non-sensitive example. Confirm scope, responsibilities, fees, and terms before any work; an inquiry does not authorize order changes or establish processing approval.

Procurement event separation sheet

Use one real purchasing thread. Record only references you can open or quote, and write none or unknown instead of upgrading a request into an order. The final column is completed by the reviewer.

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.

Procurement event separation sheet. The last column is for temporary notes.
Record or checkDecision purposeYour finding
Original artifact and identifierFixes whether the thread begins as requisition, approval notice, PO, checkout submission, invoice, or payment message.
Buyer requester and stated roleShows who asked for goods without proving they can commit the buyer.
Internal approval referenceRecords the buyer-side approval stage separately from any issued PO or agreement.
Issued PO number, entity, date and totalIdentifies the commercial commitment the buyer says was sent, if one exists.
Store draft, order, invoice and payment referencesSeparates your draft from an accepted order and from settlement evidence.
Quantities and release ruleDetermines whether the confirmed event authorizes the exact hold requested.
Gap owner and next decisionAssigns buyer purchasing, merchant acceptance, or finance matching when the records do not align.

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.

Limits

  • A requisition, approval notice, draft order, invoice, or payment reference is not by itself a confirmed merchant order.
  • Oracle and Shopify examples describe their documented workflows only; do not copy them onto another procurement suite or store platform.
  • This page gives record-based administrative guidance only and does not decide contract formation, purchasing authority, tax, credit, product suitability, or provider eligibility.
  • Do not place payment credentials, card data, identity documents, full bank details, or private portal links in worksheets or public inquiries.

Related guides

Sources

  • Oracle iProcurement User Guide: Approving Requisitions — checked 2026-10-01. Requisition approval is a workflow stage with its own notifications, and creation and approval of a resulting purchase order or agreement are separate events.
  • Shopify: Draft orders and invoices — checked 2026-10-01. A merchant can create a draft order and send an invoice with a checkout link; a paid draft becomes a regular order, and recording a payment is distinct from drafting an order.

Get help with checkout

Is this happening on your own store?

Get help with checkoutAll resources