Intro to Ramp Procurement | Demo

The short version

Your team is still running procurement through email. Someone fills out a PDF requisition, sends it to a manager, who forwards it to finance, who types up a PO in a separate system. Weeks later someone digs through a shared AP inbox trying to match an invoice to whatever was originally approved. The reason invoices go missing isn't a tooling failure. It's a handoff failure.

In this walkthrough, TK Kong and Chris Sumida demoed how Ramp Procurement fixes the four handoffs that break most procure-to-pay workflows: intake, approval, PO issuance, and invoice matching. Nevada Partnership for Homeless Youth (NPHY) used this workflow to cut their procurement cycle from 30 days to 2 to 3 days, drop per-PO processing time from 1 hour to 25 minutes, and avoid hiring 1 to 2 additional staff.

If you're still routing procurement requests through email and PDF templates, this walkthrough is for you.

Top 5 takeaways from this webinar

1. The intake form is the source of truth

The most important piece of Ramp Procurement isn't the purchase order. It's the intake form that feeds it. Questions on the intake form map directly to PO fields like billing contact, net payment terms, vendor address, and promised dates, so the PO auto-generates without re-keying. The form does work your AP team used to do by hand, which is why NPHY's per-PO processing time dropped from 1 hour to 25 minutes once the form already captured everything the PO needed.

2. Conditional questions kill the incomplete-request problem

Ramp's form builder uses conditional logic so your employees only see the questions that matter for their specific request.

• If a contractor request involves sensitive data, follow-up questions on the procurement approval form about which tools and what data appear automatically
• If it's a new vendor instead of a renewal, additional questions about vendor details and procurement timing load in
• If the request is on the vendor's paper, an order-form upload field appears

You stop chasing missing context, and your employees stop staring at a blank PDF wondering what to put in section 4.

3. Approvals route on any condition you set

Approval routing in Ramp isn't limited to amount and department. You can set conditions based on the answers employees give inside the intake form.

• If "will they need access to sensitive data" returns yes, IT and security route in automatically
• If the amount clears $10,000, FP&A gets pulled in
• Direct managers can be required on every contractor request regardless of dollar value

Ramp notifies approvers through Slack, Teams, or email, and the audit log captures the whole chain so no one reconstructs who approved what after the fact.

4. Virtual cards are a real alternative to POs

A good rule of thumb: traditional POs and invoices make sense for high-dollar or contracted vendor spend. For software, office supplies, and other low-dollar or recurring categories, configure the Spend Program to issue a virtual card instead. The card carries pre-spend controls baked in, so out-of-policy purchasing isn't a worry, and invoice volume comes off your AP queue.

This is a per-program configuration choice, not a global setting. You can run PO-based procurement for contractors and card-based procurement for SaaS inside the same Ramp instance.

5. POs are editable after issuance, with one exception

You can modify PO amount, description, and line items after a PO is issued, and the activity log captures every change. The one field you can't update post-sync is the line item type (expense vs. item), due to a constraint on the NetSuite side. If you change a PO number after it's already been sent, update the vendor directly.

Why does fixing procurement start with handoffs, not tools?

The real procurement problem isn't your tools. It's the handoffs between them. Most procurement conversations start with "we need a procurement system," but the better question is which handoffs in your current process are still happening by hand.

Walk a typical mid-market procurement workflow and you'll find four of them. An employee fills out a PDF requisition and emails it to approvers one by one. Approvers respond in a thread that may or may not loop in the next reviewer.

Your finance team receives the fully approved request in a shared AP inbox and types up a PO in a separate system. When the invoice arrives, someone digs through the inbox to find the PO and matches the two line by line.

Every one of those handoffs is a place where requests get lost, fields get retyped, or invoices land without a corresponding PO on file.

Michelle LaBonney at NPHY described it bluntly:

"I cannot tell you how many times I've gone back to that AP email and not been able to find a PO because somebody either didn't name it, or I don't know what the PO number is because it was never even submitted in the first place."

You don't fix procurement by buying a better PO generator. You fix it by removing each handoff and letting structured data flow from intake to payment without anyone retyping anything. That's why the intake form does most of the heavy lifting in Ramp Procurement.

The technique behind all 4 steps: Form-to-PO field mapping

The core idea behind Ramp Procurement is that every question on the intake form maps to a purchase order field. Once you set up that mapping, the PO writes itself.

1. Open Spend Programs and create a new procurement program: Name it for the spend category (contractors, software, hardware, inventory). Choose procurement as the program type, not card.
2. Build the intake form in the drag-and-drop builder: Add the questions employees need to answer. Use text, paragraph, number, date, single-select, multi-select, file upload, address, or contact field types.
3. Map fields to PO data: For any question whose answer belongs on the PO (vendor address, billing contact, net payment terms, promised date, line items), explicitly map it to the PO field. This is the step that eliminates manual keying downstream.
4. Layer in conditional questions: Set follow-up questions to render only when a prior answer triggers them. Contractor needs sensitive data access? Ask what tools and what data. Using vendor's paper? Ask for the order form upload.
5. Set the approval policy: Add conditions on amount, employee role, entity, direct manager, department, location, or any answer from the form itself. Add parallel or sequential branches for IT, security, FP&A, or legal review through the Ironclad integration.
6. Choose the default payment method: Purchase order for traditional procurement, virtual card for categories where card controls are more efficient than invoice matching.
7. Publish the program: It now appears in the employee's "Request spend" menu, ready for submission.

As TK explained during the demo:

"You can also map to the purchase order fields, like the billing contact, net payment terms, vendor address, promised dates, other information that you'd wanna collect onto a PO. So it really creates this guided experience by using conditional questions that's available to you on ramp procurement."

If you want a place to begin, open the one PDF requisition your team uses most often. List every field on it and decide which belong on the PO versus which are upstream approval context. That list becomes your first Ramp intake form.

TK Kong's 4 steps to remove the procure-to-pay handoffs

Step 1: Build a guided intake form

The problem the form solves. Your employees submit incomplete requests because the existing template doesn't ask the right questions in the right order. You either bounce the request back (delaying the purchase) or fill in the gaps yourself (creating downstream errors). For contractor requests specifically, security and IT context is missing more often than not, and you have no way to know whether to loop them in.

The build. In the demo, TK opened Spend Programs and created a fresh "Procurement contractor" program live. He dragged in a boolean field ("Will they need access to sensitive data?") and added a conditional follow-up text field that only appears when the answer is yes ("What tools will they need access to?"). He added a file upload field for the contractor's quote and noted that for generalized programs like contractor or software requests, finance teams typically allow any department to submit.

The requirement. The form requires a direct manager approval on every contractor request, regardless of dollar value. This is a good fit for any program where individual judgment about fit matters more than dollar threshold.

The demo. Once published, the contractor program appeared in the employee’s "Request spend" menu. As she filled it out, the conditional questions rendered live based on her prior answers, and the approval preview showed Ironclad contract review queued as part of the workflow.

Step 2: Route approvals on form answers

The problem the routing solves. Most approval policies route on amount and department alone, which misses requests that should pull in security, IT, or legal but don't trip a dollar threshold. A $4,000 contractor with access to your customer database is a higher-risk request than a $40,000 SaaS renewal, but a dollar-based policy treats them the opposite way.

The build. You can layer multiple conditions on a single approval policy. For the contractor program, TK configured four:

1. Always require direct manager approval
2. If "needs access to sensitive data" = yes, route to IT and security (parallel or sequential, depending on whether the reviews block each other)
3. If amount > $10,000, route to FP&A for budget review
4. Trigger an Ironclad workflow for legal review when the request needs contract approval

The requirement. IT and security can run in parallel or sequentially. Parallel keeps both checks moving at once when neither depends on the other; sequential makes sense when one reviewer's decision needs the prior one as input.

The demo. When the employee submitted their contractor request, the approval chain was visible to them immediately: Jeff (manager), Kevin, Peter, and Patrick (IT and security in parallel), and the Ironclad workflow for legal. Ramp notified approvers through Slack, Teams, or email, and the activity tab on the request captured the full audit trail.

Step 3: Auto-generate the PO

The problem the auto-generation solves. This is the step that consumed most of NPHY's pre-Ramp procurement cycle. After a request cleared approvals, Michelle's team manually typed up a purchase order in a separate system, then went back to the AP inbox later to find it for invoice matching. 1 hour per PO, every time. If your process looks similar, you're probably spending just as much time on manual keying.

The build. When a Ramp request clears its approval workflow, the PO auto-generates using the mapped intake form data. You can pre-code accounting categories on the PO before it's issued, which carries those codes forward to the matched invoice automatically. The PO syncs directly to NetSuite or QuickBooks and can be sent to the vendor from inside Ramp, with line items, net payment terms, billing and shipping addresses, the promised date, and any attached quotes or contracts.

The requirement. You can modify POs after issuance (amount, description, line items), and the activity tab logs every change. The one exception is line item type (expense vs. item), which can't be modified once a PO has synced to NetSuite due to a NetSuite-side constraint. If you change a PO number after the original send, notify the vendor directly since the audit log lives inside Ramp.

The demo. TK customized PO numbering with a company prefix, set a default billing address, added a company logo, and downloaded a sample PO as a PDF. The PO carried the line items, memo, footer text, and any uploaded contract directly onto the document. Then he edited an existing PO from $112,000 to $200,000 and showed the change appearing in the activity log right after.

Step 4: Two-way invoice-to-PO matching

The problem the matching solves. Invoices arrive without a corresponding PO on file, or with a PO that can't be found in the inbox, or with line items that don't quite match what was originally approved. You manually reconcile each one, recode the accounting categories that should have carried over, and chase anyone who might know what the purchase was actually for.

The build. Ramp's OCR engine reads incoming invoices from your AP email inbox and drafts them in Bill Pay. You open a draft, match it to a purchase order, and collapse line items from the invoice into line items on the PO. Any accounting categories pre-coded on the PO inherit onto the invoice automatically. Once paid, the PO updates the remaining budget in real time and closes out when fully paid down.

The requirement. Code accounting categories on the PO at issuance, not on the invoice at receipt. As TK described it:

"If I pre coded the accounting categories on the PO, then those will be connected to bring in the accounting coding onto the invoice directly, saving time, and also ensuring accuracy on the coding of the invoice.”

Inheriting codes downstream is faster and more accurate than recoding at the invoice stage.

The demo payoff. TK matched a LinkedIn invoice to its corresponding PO live, mapping each invoice line item to a PO line item. Accounting codes carried over automatically and the PO's remaining balance updated in real time. The matched record syncs to the accounting system, linking the invoice and PO in the ERP without double entry.

NPHY’s result: 30 days to 2 to 3 days

Nevada Partnership for Homeless Youth cut their procurement cycle from 30 days to 2 to 3 days after switching to Ramp.

• Procurement cycle time dropped from 30 days to 2 to 3 days: A key change was replacing the email-based approval chain with automated routing through Slack, Teams, or email.
• Per-PO processing time fell from 1 hour to 25 minutes: Auto-generating POs from approved intake data removed the manual keying step that consumed most of that hour.
• Headcount additions avoided: Michelle's team had been considering hiring 1 to 2 additional staff to handle procurement volume, and they didn't need to. If you're facing similar headcount pressure, this is the kind of result Ramp can deliver.

What should your team do to take back control?

1. Open the one PDF requisition your team uses most often: List every field on it. Mark which fields belong on the PO and which are upstream approval context. This becomes your first Ramp intake form. Send the list to whoever owns Ramp configuration at your company.
2. Audit your current approval routing for the gap between dollar threshold and risk: Find one request type where the dollar amount doesn't reflect the actual risk (contractor access to sensitive data is the classic example). Document a routing condition that catches it on form answer instead of amount.
3. Pick one spend category to move from PO to virtual card: Software subscriptions or office supplies are the easiest first targets. Configure that program to issue a virtual card with pre-spend controls instead of a PO and invoice. Give your AP team that invoice processing time back.

Final thoughts

Ramp Procurement is simple to set up but powerful enough to automate your entire procure-to-pay workflow. Unlike older procurement tools that take months and require consultants, Ramp Procurement is fast to set up.

Lost POs in a shared AP inbox are the kind of pain Ramp Procurement is designed to remove. The work isn't getting harder. The handoffs are. Every PDF emailed individually, every approval chased in a thread, every PO retyped from an inbox is a place where the process breaks.

Remove the handoffs.

See how Ramp fits in

If you're still dealing with PDF requisitions, shared AP inboxes, and manually typed POs, you can fix all of that with one workflow. One intake form that feeds the PO, one approval policy that routes on the conditions you care about, and one platform that ties requests, POs, and invoices together.

FAQs

Does Ramp Procurement work with NetSuite and QuickBooks?

Yes. POs sync directly to NetSuite or QuickBooks once issued, and matched invoices sync back to the ERP linked to the originating PO. The integration carries accounting codes pre-coded on the PO through to the invoice without re-entry.

Can we run virtual cards and traditional POs inside the same Ramp instance?

Yes. The payment method is a per-program configuration choice, so you can run PO-based and card-based programs side by side. Traditional POs and invoices make sense for high-dollar or contracted vendor spend, while virtual cards with pre-spend controls work better for software, office supplies, and other low-dollar or recurring categories.

What happens if a PO needs to change after it has been issued?

You can edit the amount, description, and line items on an issued PO, and the activity tab logs every change. The one exception is line item type on POs that have already synced to NetSuite, which is locked by a NetSuite-side constraint. Notify the vendor directly when a PO number changes after the original send, since the audit log lives inside Ramp.

Where should we start if we have never run procurement through software before?

Start with one spend category that has clear, repeatable requirements. Contractors and software both work well as a first program because the intake questions are stable and the approval logic is straightforward. Build one program end to end with Ramp Procurement (intake form, approval policy, default payment method), publish it to one department, and use what you learn to template the next category.