The problem
Most purchase approvals spreadsheets start as a simple log: date, vendor, amount, who asked, who said yes. Then someone adds a budget column, then a tab per month, then a color rule. Two years later the file has fourteen columns and a rule that only one person remembers.
The spreadsheet records decisions. It does not make them. Approval happens in email or chat, and someone types the result into a row. That gap is where trouble lives. Two people edit the same row and one version wins silently. An approver goes on leave and nobody knows who takes over. Finance learns about a purchase when the invoice arrives, weeks after the money was committed.
Ask a simple question and the sheet struggles: who approved this, when, and against which rule? Version history shows cells changing, not intent. Thresholds live in people's heads. There is no way to show that the person who requested the purchase was not also the one who approved it. Access is coarse too: on a shared drive you can edit everything or nothing, so contractors and new hires get more access than they need.
What a good solution looks like
A purchase approval app is not a prettier spreadsheet. It is a small workflow with a database under it. The request is a record with a status. The status changes only through defined actions, and each action writes a row to a history table with an actor, a timestamp and the before and after values.
Four parts matter most. A request form that asks for vendor, amount, currency, cost center, budget line, justification and a quote, with required fields enforced at submit. Routing rules stored as data: amount bands, cost center owner, backup approver and delegation dates. Notifications with escalation, so nothing sits for a week because one email was missed. Segregation of duties: the requester cannot approve their own request, and the approver cannot be the person who records the invoice or marks it paid.
Access should come from your identity provider. Map groups to roles: requester, approver, finance, auditor. Auditors get read-only access to everything, including history, which removes most requests for spreadsheet copies. Design the finance export early: approved requests, amount, currency, cost center, purchase order number, approval date, with stable column names. Your accounting team will depend on it every week.
How to build it
Write down the rule set you actually use. Pull the last fifty rows from the spreadsheet and reconstruct what happened: who approved, at what amount, how long it took, which requests skipped a step. You will find exceptions. Decide which become rules and which you drop. That document is the real specification.
Model the data. A minimal set is enough: users, vendors, cost centers, requests, decisions, attachments, comments. Store money as an integer in minor units with a separate currency column, never as floating point text. Keep a status field on the request for speed, but treat the decisions table as the source of truth.
Pick the smallest stack your team can operate. A server rendered web app, one relational database and a scheduled job for reminders will carry this for years. Sign in with your identity provider using OIDC or SAML and map groups to roles. Build routing as rows in a table keyed by amount band and cost center, then replay past requests to check that the computed approver matches who actually approved.
Handle notifications carefully. A daily digest at a fixed hour beats a message per event. Add escalation: after a set number of business days, remind the approver, then copy the backup, then the cost center owner. Store the send time so a restart does not send twice. Import open requests only, freeze the old spreadsheet, and link a read-only copy from the new app so history is still findable.
Risks and how to manage them
The biggest risk is a shadow process. People keep emailing approvals because it is faster, and the app becomes a second job. Tie the purchase order number to the app: no approved record, no PO. Say it once, then hold the line for a month.
Threshold splitting comes next. Someone divides a purchase in two to stay under a limit. Warnings will not stop it, but you can surface it with a weekly report that groups requests by vendor and week and flags totals above a band. Naming the pattern in a review is usually enough.
Watch permissions drift. People change roles and keep old access, so sync roles from identity provider groups instead of assigning them by hand, and review the approver list each quarter. Vendor names are another quiet mess: free text produces five spellings of one supplier, so use a vendor table with a picker and a new vendor form that routes to finance.
Protect the audit trail. Make the history table append-only, with no edit or delete in the interface and a database account that cannot update it. Keep amounts in minor units with an explicit currency, and never total mixed currencies in one column without a rate and a date attached. Guard scope too. The app will attract requests for budgets, receipts and full procurement. Ship approval first.
How to measure success
Measure the process, not the software. Track median time from submit to first decision and the share of requests decided inside your window. Track how many arrive complete, with every required field and a quote. If that number climbs, the form is doing its job.
Count the leak. Each month, sample purchases and check how many were approved outside the app. Aim for zero and look into each one you find. Also count questions sent to the person who used to own the spreadsheet. That number falling means the rules now live in the system.
For finance, time how long the weekly committed spend view takes to assemble. Before, it was an afternoon of copy, paste and cleanup. After, it should be one export. Check that every closed request has a chain of decisions with an actor and a timestamp. That is the number auditors care about.
Review at thirty and ninety days. Look at the exception log, the split purchase report and approver response times. If one approver is consistently slow, the fix is delegation, not more reminders. If you would rather not build it in house, options range from a low-code platform to a contract developer to Cloudverg's Internal tool sprint, a fixed price of $16,500 over four weeks that covers one workflow end to end, sign-in with your identity provider, roles, change history, data import, exports, training and a written runbook.
Frequently asked questions
Can we keep using the spreadsheet for small purchases?
Yes, and many teams start that way. The app can auto approve requests below a band you set with finance and still record them, so the audit trail stays complete without extra work. Write the band as a rule in the app rather than a habit in someone's head.
How long does it take to build a purchase approval app?
A single workflow with roles, history and exports is a few weeks of focused work, not a year. Most of the effort goes into writing down the rules and cleaning the vendor and cost center lists, not into code. Start with approval only and add features once people use it.
Who should own the app after launch?
Operations usually owns the process and IT owns the deployment. Name one person who can change routing rules and one who manages access, and put both in a runbook. Otherwise the app becomes a new single point of failure with a nicer interface.