Payment controls and records

The final order exceeds the buyer’s written purchasing authorization

Compare the buyer's written authorization with the final order using the same components: item lines, shipping, tax, fees, currency and total. Do not treat a checkout calculation, a draft invoice or a willing purchaser as spending authority. Oracle's iProcurement documentation keeps requisition approval separate from creation and approval of the resulting PO or agreement, and Coupa directs suppliers to request a buyer change order for an invoice/PO amount mismatch. If the final total is outside the written cap or the cap's scope is unclear, hold acceptance and request a documented adjustment from the authorized buyer owner. Shipment beyond the approved limit needs that buyer-side decision, not a platform total.

For: Authorized staff of a research-only merchant deciding whether a final institutional order fits the buyer's written purchasing authorization.

Updated 2026-10-01

Get help with checkout

Read the authorization as a scoped document

Find the buyer's written authorization: approved requisition, PO, blanket agreement release, quote acceptance or delegated purchasing limit. Record the buyer legal entity, approver role, issue date, currency, expiry, products covered, and whether the cap is per line, per order, per shipment or per period. A number without scope is not yet a usable limit.

This page concerns the buyer's internal purchase authority. It is different from a provider transaction limit, which belongs to the merchant's payment account, and different from explaining why a checkout total differs from a product price. Keep those investigations separate so a merchant-side limit or a tax explanation is not mistaken for buyer permission.

If the authorization says 'not to exceed' a value, write exactly what the document says counts toward that value. If it is silent on shipping or tax, mark the treatment unresolved rather than choosing the interpretation that makes the order fit.

Rebuild the final total from the same components

Use the final proposed order, not the earlier estimate. List item quantities and extended prices, discounts, shipping, tax, any separately recorded fees, currency and grand total. Label each amount as included or excluded so shipping and tax are not compared against a cap that excluded them, or counted twice.

A draft invoice or checkout page can display a total without proving authority. The useful comparison is between the final documented total and the written cap under the same basis. If the buyer's cap was pre-tax and your invoice is post-tax, say that explicitly and ask the buyer owner which basis their approval used.

Oracle's older iProcurement guide illustrates why an approval stage should not be stretched: requisition approval is its own workflow stage, while creation and approval of the resulting PO or agreement are separate events. Use that distinction to avoid treating an early approved request as approval for a later, larger final order.

Route an over-cap order to the authorized buyer owner

When the final total exceeds the written cap, or the cap does not clearly cover shipping, tax or a changed line, pause acceptance. Send the buyer owner the exact difference, the components causing it, the current PO or authorization reference, and the proposed final total. Ask for a documented decision that names the new limit, changed lines, change order, split approval or rejection.

Coupa's supplier guidance supports requesting a buyer change order when invoice and PO amounts mismatch, and it keeps PO changes, invoice approval and payment with the buyer. That is a Coupa workflow example, not a universal rule, but the ownership point is practical: the merchant cannot unilaterally expand the buyer's authority.

Do not split the order into smaller invoices to fit under a cap, omit shipping from the authorization comparison, or ship the excess as samples. Those actions conceal the obligation instead of obtaining authority.

Record the decision without deciding legal or provider questions

Close the worksheet with one state: within written authorization, conditionally within after documented buyer adjustment, outside authorization awaiting buyer decision, buyer declined, or scope unresolved. Attach the dated buyer response and name the merchant person allowed to release acceptance after it arrives.

If the buyer increases authority, verify the new document covers the same entity, products, total basis and expiry before invoicing or reserving stock. If the buyer reduces the order, update lines and totals through the agreed correction route and keep the prior version for audit.

Contract authority, tax calculation, credit risk, public procurement rules, product suitability and payment-provider eligibility remain outside this administrative page and need the appropriate qualified owner. For a recurring storefront concern where quotes, checkout totals and buyer caps diverge, you may describe the issue to Prism with non-sensitive records; confirm scope, responsibilities, fees and terms before work.

Buyer authorization comparison

Use one final proposed order and one written buyer authorization. Compare like with like, including shipping and tax basis. The reviewer completes the final column; unresolved scope is not approval.

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.

Buyer authorization comparison. The last column is for temporary notes.
Record or checkDecision purposeYour finding
Written authorization source and scopeFixes buyer entity, approver role, currency, expiry and whether the cap is per line, order, shipment or period.
Final item lines and discountsEstablishes the goods amount before delivery, tax or fees are compared.
Shipping, tax and fee treatmentShows whether the cap includes or excludes the components that pushed the total upward.
Final total on the authorization basisDetermines whether the documented cap is exceeded using the same components.
Approval stage separationPrevents an approved request from being treated as approval of a later larger PO or order.
Buyer adjustment request and responseRecords the exact change order, new limit, line reduction or rejection from the authorized buyer owner.
Merchant release ownerNames who may accept, invoice or reserve stock only after the buyer-side decision is documented.

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 platform total, draft invoice or purchaser enthusiasm does not prove the buyer's spending authority or permit shipment beyond a written cap.
  • Oracle and Coupa examples describe documented workflows and ownership distinctions; they are not a universal purchasing-authority or legal test.
  • Do not split, relabel or omit amounts to make an over-cap order appear within authorization.
  • This page gives administrative record guidance only and excludes legal, tax, credit, product-suitability and provider-eligibility conclusions.
  • Keep payment credentials, card data, identity documents, full bank details and private portal links out of the worksheet and public inquiry.

Related guides

Sources

  • Coupa: Help for Suppliers — checked 2026-10-01. The buyer manages supplier setup, purchase-order changes, invoice approval and payment; for an invoice/PO amount mismatch the supplier is directed to request a buyer change order, and invoice comments or history can explain a disputed status.
  • 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.

Get help with checkout

Is this happening on your own store?

Get help with checkoutAll resources