Software purchasing does not need an ERP: it needs every tool to have someone who requests it, someone who approves it, someone who pays for it and a date when it gets reviewed. With a catalog of what is already approved, a request that says who it is for and why, one approver per department and a purchase order tied to the payment and the invoice, a company of 20 to 500 people can get its purchases in order in a week. You can start with a spreadsheet and a form; once renewals start slipping past you, you need something more.
Updated on October 11, 2026 · 8 min read · Mekovault
Someone in marketing needs Canva. They message their manager on Slack, the manager says “sure”, and the person pays with their own card and files an expense report. Sales signed up for a CRM two years ago on the sales director’s card; it bills every month and nobody remembers how many users it has. Design pays for Adobe with a card that expires next month. Finance finds out about all of it when the statement arrives.
This is not carelessness: it happens because nobody defined who requests, who approves, who pays and who reviews. At a company of 20 to 500 people with no IT department, software gets bought the way coffee gets bought: when it is needed, with whatever is at hand. The problem shows up later, when there are three tools for the same job, a subscription belonging to someone who left, and an annual renewal that charged itself.
An ERP solves purchasing of supplies, warehousing and accounting for large companies. For software, IT procurement needs far less. These are the pieces:
The workflow does not change with company size; what changes is who holds each role. At a 30-person company, the same person may buy and pay. At 300 people, those are separate departments.
| Step | Who | What gets recorded |
|---|---|---|
| 1. Request | The person who needs the tool | Who it is for, what for, what it costs, whether it is in the catalog or new |
| 2. Approve | The direct manager; if new or over the threshold, also budget control | Who approved, when, against which budget and cost center |
| 3. Buy | The buyer (procurement or office administration) | Purchase order, vendor, plan purchased, credentials stored |
| 4. Pay | Treasury or finance | Payment method, billing cycle, invoice attached |
| 5. Renew or cancel | Whoever administers the tool, with the manager | Renewal date, decision to keep, reduce or cancel; license released when someone leaves |
What matters about the record is not the format: it is that each step leaves a fact the next step uses. The purchase order comes from the approved request; the invoice is tied to the order; the renewal is reviewed against the date on the order.
A purchasing system fails for one of two reasons: it is so heavy that people skip it, or so light that it does nothing. These rules keep it in the middle:
You do not need procurement software for small business to get started. You need a form and a spreadsheet. The form collects the request: name, department, tool, what for, cost, billing cycle. The spreadsheet has one row per tool with these columns: tool, plan, price, billing cycle, owner, cost center, payment method, renewal date, status. The approver replies to the form’s email; the buyer adds the row; the payer records the invoice.
That works until one of these happens: the spreadsheet passes 30 rows and nobody updates it; an annual renewal slips by because the date was written down but nobody looked; someone left the company and their Figma license kept billing for six months; or the CEO asks “how much do we spend on software?” and the answer takes a week. At that point, the purchasing system needs to send the reminders itself, not wait for someone to open the spreadsheet.
Software purchasing is the five-step workflow in this guide, with six roles: Requester, Manager, Control, Purchasing, Treasury and Administrator. Someone requests a tool from the catalog or a new one. The manager approves with one click if it is in the catalog; if it is new, it goes through Control with budget and cost center, then through Purchasing. Purchasing issues the purchase order as a PDF, records the vendor and stores the credentials. Treasury pays by corporate card or bank transfer, records the billing cycle and gets the invoice reminder. If nobody responds within 48 hours, the next person is notified.
Every subscription keeps its renewal date, and 30 days before it the reminder arrives to decide whether to keep it, reduce the quantity or cancel. When a person leaves, the license they had is released or reassigned instead of staying on the bill. Tools with no connector (Canva, Notion, Adobe and the rest) are entered by hand with price, renewal date and owner, and they join License control alongside Google Workspace. If you already have a spreadsheet, it imports in one go. Before deciding, you can estimate how much you are losing on licenses with the calculator.
No. An ERP handles supplies, inventory and accounting for large companies. For software, what you need is a workflow with four roles (who requests, who approves, who buys, who pays) and a record where every tool has a request, a purchase order, an invoice and a renewal date. That fits in a spreadsheet at first, and in a module like Mekovault's Software purchasing later.
It is the document where the company states what it is buying, from whom, for how much and how often, before paying. For software it matters because it records the cost center, the renewal date and who authorized it. When the card charge shows up, you know where it came from.
With a deadline and a next person. The practical rule is 48 hours: if the manager does not respond, the request moves to the next person defined (for example, budget control or the system administrator). Without that rule, requests sit in email and people end up paying with their own card.
Make sure no spend exists without a request. If every tool starts with an approved request, a purchase order and a linked invoice, controlling spend means looking at that list, not rebuilding the statement. The charges with no request behind them are the ones to chase.