Insights · 12 min read
What an expense management system is made of, which modules matter, where AI earns its keep, and what a build realistically costs and takes.
By GGP Editorial
Most companies do not set out to build expense software. They start with spreadsheets and shared folders, then someone forwards a receipt in a chat app, then finance spends a Friday afternoon chasing approvals and matching card statements by hand. At some point the person who owns the numbers decides the manual route has to stop. That is when the options get compared: buy a tool like SAP Concur or Expensify, or build something that fits the way the company actually works.
This guide is for two kinds of readers. The first is a finance leader or founder who wants to understand what goes into building this system before talking to developers. The second is a team that plans to sell expense software as a product, the way Ramp and Brex did. The scope is different for each, but the core modules are the same, and most of the mistakes are too.
Strip away the marketing and the workflow is a loop with five steps. An employee pays for something with their own money or a company card. They submit the expense, usually with a photo of the receipt. A policy check runs against the claim, covering amount, category, date, merchant, and project. A manager or finance approver signs off, or the system rejects it. The approved amount is then reimbursed or matched against a card statement and pushed into the books.
Everything else, OCR, approval chains, budgets, dashboards, is built around that loop. If the loop works, the rest is addition. If the loop is clumsy, no amount of reporting saves it.
The market already has mature products here: SAP Concur, Expensify, Ramp, Brex, Zoho Expense, and the expense modules inside QuickBooks and Xero. They handle the standard case well. Companies build their own when the standard case does not fit. The most common triggers are approval rules the generic tools cannot express, multi-entity or multi-currency needs, integration with a homegrown or enterprise ERP, or a workflow tied to industry data like jobs, projects, or clients. Field staff who claim expenses against a specific job site are a classic example that generic tools handle poorly.
I will list them in the order they matter, not the order they appear on a sitemap.
This is the module employees see first. People need a fast way to log an expense: a mobile app, a web form, or email forwarding. The receipt is the hard part. A decent OCR pipeline extracts the merchant, date, amount, currency, and tax, then maps the merchant to a category. Extraction itself is rarely the problem today. The edge cases are. Folded receipts, foreign currencies, receipts in Portuguese or Chinese, handwritten amounts, hotel folios split across rooms. Budget real time here, because OCR that works on clean scans but fails on real receipts generates support tickets forever.
This is where a custom build pays for itself. A policy engine evaluates every claim against rules: spend limits by role or department, allowed categories, per diem rules, mileage rates, project codes, approval chains. Generic tools let you set some of this. They rarely let you model something like a regional sales manager who can approve up to $500 in their own territory, but any expense tagged to a client project over $200 needs the project owner to sign off. If your rules look like that, the policy engine is the main reason to build.
Money moves two ways. Reimbursement is the older path: the employee pays, the company pays them back through payroll or a bank transfer. Card sync is the newer one: corporate or virtual cards feed transactions into the system automatically, and the employee just attaches a receipt and picks a category. Card sync needs bank or card provider APIs, which adds integration work and usually a vendor agreement. Reimbursement needs a payout step, either a manual export or a payout API.
The system has to end somewhere, and that somewhere is your books. The integration posts approved expenses into the general ledger as journal entries, mapped to the right accounts, departments, and cost centers. If you run QuickBooks or Xero, this is well-trodden ground. If you run SAP, Oracle NetSuite, or a custom ERP, plan for real integration effort. Multi-currency adds a layer: you need exchange rates, and you need to decide when a rate locks.
Finance wants spend by department, project, and employee. Auditors want a record of who changed what and when. Build the audit log from day one. Retrofitting it later is painful, and in a regulated environment you may not have the choice to skip it.
Here is the same list compressed:
| Module | Core function | Complexity driver |
|---|---|---|
| Receipt capture and OCR | Digitize receipts, extract merchant, date, amount, tax | Receipt quality, languages, currencies |
| Policy engine | Enforce spend rules and approval chains | Number and type of rules |
| Reimbursement and card sync | Pay employees back or match card transactions | Payout or card APIs, vendor agreements |
| Accounting integration | Post expenses to the general ledger | Target ERP, multi-entity, multi-currency |
| Reporting and audit | Spend analytics and immutable history | Regulatory and auditor requirements |
Receipt OCR has been machine learning for years, and it is now good enough that you should not spend months building it from scratch. Use an existing document extraction service for the heavy lifting and write the logic around it. The higher-value AI work sits one level up.
Auto-categorization. When an employee snaps a taxi receipt, the system should file it under travel without asking. This works well for common merchants and gets worse on the long tail. Plan for a confidence threshold: above it, categorize automatically; below it, ask the employee.
Anomaly and duplicate detection. Two receipts for the same amount from the same merchant on the same day, a meal claim over the per diem, a hotel that looks like a duplicate of an earlier submission. These checks save finance real time and catch mistakes before they reach the approver.
Policy nudges. Instead of rejecting a claim outright, flag it: this meal is 40% over your daily limit for the city. The approver still decides, but the system did the triage.
One honest note: AI here reduces the finance team's workload. It does not replace the approver. Build it to assist and flag, not to auto-reject, unless your policy is genuinely hard. The same pattern shows up across business software, which we wrote about in how to add AI to existing business software.
Before you ask for a quote, decide these six things. Each one changes the build significantly.
Single entity versus multi-entity. One legal entity with one currency is the simple case. A holding company with subsidiaries in three countries, each with its own tax rules and chart of accounts, is a much bigger build.
Mobile or web only. Field staff need a mobile app. Office staff can live with web. A native app for iOS and Android roughly doubles the front-end effort compared to a responsive web app.
Card integration or manual. Corporate card sync is smoother for employees but needs bank APIs and vendor agreements. Starting with manual reimbursement is cheaper and faster to launch.
Which accounting target. QuickBooks or Xero is fast. A custom ERP or SAP is not. If you have more than one accounting system, budget for a sync layer.
Compliance depth. Mileage rates and per diem limits change year to year in most countries, and the tax rules for reclaiming VAT or GST on expenses vary by jurisdiction. If you operate across borders this is real work, not a checkbox. Confirm current rates and rules with your finance team or accountant rather than baking assumptions into the code.
Scale. Fifty employees is one thing. Five thousand with concurrent month-end reporting is another. Architecture choices you can ignore at fifty matter a lot at five thousand.
There is no single number, because the build is not a single shape. A useful way to think about it is in three bands.
An MVP for a single entity, web app, manual reimbursement, one accounting integration, basic OCR, and a simple policy engine is a three-to-four-month build for a small team of around four people. Think of it in the tens of thousands of dollars, not six figures.
A full system with a mobile app, card sync, multi-currency, a flexible policy engine, and real reporting lands in the six-month-plus range with a larger team. The number depends heavily on the integrations and the number of entities.
An enterprise build with multi-entity, integration into SAP or NetSuite, deep compliance, and audit requirements is a multi-quarter program, not a project, and the price reflects that.
These are indicative ranges, not quotes. What actually drives your number is the scope decisions above, especially entities, integrations, and compliance. For a fuller look at where a custom software budget goes, see our breakdown of custom software development costs.
Buy the generic tool if your needs are standard and your accounting target is QuickBooks or Xero. The subscription is cheap compared to a build, and you can launch in days.
Build when at least two of these are true: your approval rules do not fit the generic tools, you integrate with a homegrown or enterprise ERP, you run multiple entities or currencies, or the expense workflow ties into industry data like jobs, projects, or clients.
I have seen teams spend more customizing an off-the-shelf product than a focused build would have cost, because the product's data model did not match how the business actually worked. That is the real test: whether the tool's model fits your business model, not whether the tool has more features. It is the same logic we apply to custom software versus SaaS.
Starting with OCR instead of the workflow. The receipt is the visible problem, but the approval and reconciliation flow decides whether finance trusts the system. Get the loop working with clean data first, then harden the OCR.
Ignoring the accounting integration until the end. This is the most common mistake. The system's real job is to get correct numbers into the books. Build the ledger mapping early and test it with real data, or you will ship a tool that creates more work for accounting than it saves.
Making the policy engine too rigid. Hard-coded rules break the first time someone changes a policy. Build rules as configurable data, not code.
Skipping the audit log. You will be asked at some point who approved an expense and when. If the answer is not in the system, you have a problem.
Expense software is financial software first and a mobile app second. The users care about the receipt capture; the buyer cares about the ledger. Get both right and you have a system finance actually uses instead of works around.
GlobeSoft has delivered financial systems that follow the same principle, from a financial management system where owners wanted their numbers under their own control, to billing and invoicing systems and general ledger software. In each case the workflow and the ledger mapping came first, the features second. The same ordering applies to expense software, and it is the difference between a tool that demoes well and one that holds up at month-end.
How long does it take to build an expense management system?
An MVP for one entity with basic OCR and a simple approval flow typically takes three to four months with a small team. A full multi-entity system with card sync and ERP integration runs six months or more.
How much does custom expense management software cost?
It depends on entities, integrations, mobile requirements, and compliance depth. A focused MVP starts in the tens of thousands of dollars; a full enterprise build is a multi-quarter investment. The scope decisions above determine most of the variance.
Should I build it or buy SAP Concur or Expensify?
Buy if your needs are standard and you use QuickBooks or Xero. Build if your approval rules, ERP integration, or multi-entity structure do not fit the generic tools.
Do I need a mobile app?
Only if your employees submit expenses on the go. Field staff and sales teams do. A responsive web app is enough for office-based teams.
What accounting systems can it integrate with?
QuickBooks and Xero are the most common and fastest. SAP, Oracle NetSuite, and custom ERPs are doable but add integration effort, especially with multi-entity and multi-currency requirements.
If you are weighing this build, describe what the system has to do and the workflow it has to support. GlobeSoft can tell you which modules matter, which to defer, and what an honest number looks like before you spend anything.
Tell us what you are building and where you are today. We typically reply within 24 hours.
