Ramp PO-linked cards need issuance and reconciliation rules

A PO-linked card needs an issuance authority record

The direct buyer answer is to treat card issuance from a PO as a distinct control decision. Ramp says a card can be issued directly from a PO. The buyer should specify whether the PO must be approved and active, which legal entity and requester it belongs to, who may issue or receive the card, which supplier or merchant and currency are allowed, what amount and time window apply, and what happens when the PO changes or closes. A generated card is a payment instrument tied to a commitment; the provider page alone does not establish that these exact restrictions are automatically inherited in a customer's configuration.

Retain the approved PO version, line items, supplier identity, budget and cost center, approvers, issue event, card token or non-sensitive reference, cardholder, limits, effective and expiration dates, and any override. Do not publish or export full card credentials. If an employee can create several cards for one PO, the remaining authorized balance and aggregate exposure need an explicit rule. A PO revision after issuance must not silently rewrite the authority under which earlier card authorizations occurred.

Match the card event to the correct commitment and line

Ramp describes automatic matching of card transactions to POs. For a buyer test, ask which identifier or inference links the card, authorization, posted transaction, PO header and line, merchant, amount, and currency. Test a single PO with multiple lines and cards, split shipments, a supplier operating under a different merchant name, and a card transaction that has no valid PO line. A successful automatic association may be useful evidence of linkage; it is not proof the goods were received, the price was correct, or the charge complied with contract and tax rules.

Define what each status means: card issued, authorized, captured or posted, matched, reviewed, disputed, credited, and exported. These are proposed buyer control states, not a claim that Ramp exposes every state exactly this way. The public page does not specify how refunds, reversals, partial credits, incremental authorizations, foreign exchange, tips, fees, or delayed settlement affect a match. The buyer should require a demonstration and record the remaining unknowns rather than assuming card-to-PO matching is the same as invoice 2- or 3-way matching.

Reconcile exceptions without changing the original PO

A controlled example begins with an approved PO, a card issued from one line, a partial card charge, and a later charge from a related but different merchant. Add a return, a credit, and an invoice for the unspent portion. The procurement and finance teams should reconstruct original commitment, card issuance, each authorization and posted amount, match basis, exception decision, remaining PO balance, invoice treatment, and accounting handoff. The record should preserve whether a correction was an approved amendment, a reclassification, or a rejected charge.

The control owner may differ at each step. Procurement owns the commercial PO and change authority; finance or treasury owns card issuance policy and spending limits; AP and accounting reconcile actual transactions and invoices; the budget owner approves exceptions; tax and legal review their own questions. Ramp's page supports its attributed card-from-PO and transaction-matching positioning but does not validate any customer's role assignments, effective controls, ledger treatment, savings, or prevention outcome.

Evidence boundary and next test

This analysis reviews Ramp's official Procurement page on September 22, 2026. It did not access a Ramp tenant, issue a card, process a charge, test a rule, inspect a contract or invoice, or verify an accounting entry. The card-to-PO capabilities are provider claims. Issuance conditions, transaction states, partial-spend and reversal behavior, integration behavior, and customer control results remain to be demonstrated.

The next decision is a buyer-owned PO-to-card test script with one normal transaction and deliberately conflicting cases: changed PO, duplicate card, wrong merchant, over-limit amount, partial fulfillment, and credit. Require timestamped evidence for who authorized issuance and the exception, the exact PO version, the matching rule applied, and the posted financial result. This is a narrower question than whether a generic procurement suite has an approval workflow.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Procurement Technology Current will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.