A Worked Example: Ramp or Procurify for a Small DevOps Shop

Most of this shop's cloud spend runs directly on each client's own cloud account, which the consultancy configures but doesn't pay for, so it never touches Ramp or Procurify at all. The spend that does touch the firm's own books is smaller: a shared staging environment, a couple of proof-of-concept accounts, and reseller credits for a monitoring tool the consultancy resells to clients at a markup. That last category is the one worth watching closely, since it behaves like the resale spend an MSP deals with: one consultant provisioning a client's monitoring seat on the firm's card instead of the client's own account is a common, easy-to-miss mistake.

The consultancy brings in a subcontractor for a short migration project, billed to one client at a fixed price. Under a card-first model, the consultant pays the subcontractor's invoice from a project-specific Ramp card, and the charge shows up already coded to that client's engagement. Under Procurify, the consultant submits a requisition before the subcontractor starts, naming the client, the scope, and the agreed price, and the purchase order becomes the record both sides can point to if the scope changes mid-engagement. For a shop this size, the requisition step adds a bit of lead time, which matters if the client engagement is genuinely urgent, but it also means there's a written record of what was agreed before any money moved, useful the one time a subcontractor's invoice doesn't match what was discussed.

A small consultancy invoicing this way typically waits on payment the same way any computer services firm does, receivables average around 77.7 days at firms in this category¹, more than two and a half months between finishing a migration and collecting the fee. Against that wait, the firm's own vendor bills come due faster, computer services firms pay in about 63 days on average², which means a subcontractor paid immediately from a card can sit as an unrecovered cost for weeks before the client's payment lands. That gap is the real argument for tagging every contractor cost to its client the moment it's incurred, whichever tool handles the tagging. It's also why a habit of coding spend at the point of purchase matters more here than in a business that collects on shorter terms: the longer the wait to get paid, the longer an untagged cost quietly sits as unrecovered cash.

At a very small size, most spend decisions still run through one person's judgment, and a lightweight card-based approach with good tagging habits is usually enough. The moment the shop adds another consultant, or takes on a client large enough to ask for formal purchase order documentation, that changes: judgment calls that worked when everyone could watch each other's spend start slipping through when more people are making purchases independently. That's the point to revisit Procurify, not before it, since adding requisition overhead to a very small shop mostly just slows everyone down without buying much additional control.

This particular consultancy stuck with card-based controls: per-client virtual cards with tight limits, a required project-code field on every transaction, and a short weekly review of anything uncoded. The deciding factor wasn't cost or features, it was that a short engagement doesn't leave time for a multi-day requisition cycle, and at this size, everyone already knows who's buying what. A larger consultancy with longer engagements and more consultants making independent purchases would likely land on Procurify instead, since the same judgment calls that work when four people can see each other's spend stop working once purchases happen out of view. The lesson generalizes: pick the control that matches how visible your spend already is to the people making it, not the control that looks the most thorough on paper. See Procurify vs Coupa vs Ramp for how a third option compares.

The card-based setup came down to four controls:

• Per-client virtual cards with tight limits, so each charge lands on the right engagement.
• A required project-code field on every transaction, so nothing goes uncoded.
• A short weekly review of any transaction still missing a project code.
• A written record of the client, scope and price for each subcontractor engagement before the work starts.