Approving a Ramp transaction with the right NetSuite GL code

Ramp

Open the approval inbox and click the oldest pending transaction.

Always work the inbox oldest-first. Working newest-first means transactions can age beyond the seven day approval window and Ramp escalates them to the senior RevOps manager, which adds a touchpoint nobody benefits from. Sort by date ascending and start at the top.

Expected: The oldest pending Ramp transaction is open in the approval pane.

Ramp

Verify the receipt is attached and matches the transaction line items, vendor and total.

Photo receipts that show only the total without line items go to the rejection pattern. VAT recovery requires the line item breakdown for any spend above $50 even if the total ties. A receipt with line items but missing the vendor name is fine if Ramp has already auto-populated the vendor; double-check both match.

Expected: The receipt matches the transaction or the transaction routes to rejection.

Ramp

Read the vendor name and confirm it matches the normalised vendor record.

Ramp pulls vendor names from the merchant string on the card statement and they often differ from the contracted name. `STRIPE *NOTION INC` from the card becomes `Notion Labs Inc` on the contract. Use the normalised vendor record; if Ramp has it wrong, fix the vendor before approving so future spend hits the right vendor record.

Expected: The vendor name on the transaction matches the normalised vendor record.

Ramp

Confirm the GL code matches the team owner's department, not the cardholder's.

The pre-fill from the spend programme normally gets this right but always check. If a marketer borrowed an engineer's card for a marketing event the pre-fill will say engineering and needs overriding. The team owner's department is the budget-holding team, which for shared spend is normally the team where the spend was decided not the team where the card sits.

Expected: The GL code reflects the team owner's department.

Ramp

If cross-charging, override the GL code and add a one-line memo explaining the cross-charge.

Cross-charges happen often enough that they need a memo every time. The memo names the original team and the receiving team and the reason in one short line. FP&A flags any cross-charge without a memo at the next review and the approver gets pulled into the variance investigation.

Expected: Override is in place and the memo explains the cross-charge in one line.

Ramp

Click Approve and confirm the transaction status moves to Approved.

Approve, do not click Submit and Approve unless the cardholder is the same as the approver. Submit and Approve creates audit-trail noise because Ramp logs both events. For routine approvals just click Approve once and move on.

Expected: The transaction status reads Approved and disappears from the pending inbox.

Ramp

Move to the next oldest transaction and repeat until the inbox is clear or the inbox flips to a missing-receipt rejection.

Inbox sessions normally run ten to twenty transactions. Approvals and rejections alternate naturally as the inbox flushes; if you hit two rejections in a row, batch the rejections together and message the cardholder once rather than three separate emails.

Expected: The inbox advances to the next transaction or completes the session.