Expense reimbursement app with receipt photos for faster approvals

The paperwork problem, explained simply

Receipt chasing usually starts small. Someone buys a taxi ride, stuffs the paper slip in a pocket, and plans to submit it later. A week passes, the receipt fades or disappears, and the claim turns into a message thread.

Three things cause most of the mess: receipts get lost (or never collected), rules feel unclear (what needs a receipt, what needs a note, what limits apply), and approvals move slowly (a manager is busy, finance has questions, and the claim sits unfinished).

Everyone feels it, just in different ways. Employees wait for money they already spent. Managers spend time asking for missing details instead of approving quickly. Finance retypes totals, matches card statements, and chases people right before month-end.

A simple expense app with receipt photos fixes this by making the right behavior the easiest behavior. Submitting should take under a minute. Managers should get enough context to decide without digging. Finance should end up with clean numbers that don’t need manual cleanup.

Here’s the workflow you’re building:

• Employee submits an expense with a receipt photo and a few key fields.
• The app checks basic rules (missing receipt, over limit, wrong category).
• Manager approves or sends it back with a clear question.
• Finance reviews exceptions, then exports clean monthly totals.
• Employee gets reimbursed and can see status at any time.

If you build this in a no-code platform like AppMaster, the goal stays the same: fewer “where is that receipt?” moments, and a predictable, trackable process instead of a monthly scramble.

Roles and permissions you will need

The fastest way to make an expense tool feel fair is to be clear about who can do what. A simple role setup prevents two common problems: people editing claims after approval, and finance chasing missing details for weeks.

Start with four roles. Keep permissions tight at first, then add exceptions only when you see a real need.

• Employee (claim owner): creates a claim, adds receipt photos, edits while it’s still a draft, and sees status updates. After submission, they should be able to answer questions and attach an extra file, but not change amounts unless the claim is returned to draft.
• Manager (approver): reviews, approves or rejects, and can request changes with a short note. Many teams also need a safe “delegate” option for vacations so approvals don’t stall.
• Finance (auditor): can view everything, spot-check receipts, and correct coding (like cost center or category) without changing the original receipt image. Finance should be able to lock a closed month so totals don’t shift after reporting.
• Admin (owner of settings): manages users, teams, cost centers, reimbursement methods, and policy rules. Admin should not approve their own expenses by default.

A small but important rule: separate “can see” from “can change.” Managers usually need to see their team’s claims, but they shouldn’t be able to edit an employee’s description or replace receipts.

Define a few edge-case permissions early:

• Who can submit on behalf of someone else (assistants)?
• Who can view sensitive merchants (medical, legal)?
• Who can reopen a rejected claim?

AppMaster can help here because you can map roles to screens and actions, then reuse the same rules across web and mobile apps.

What employees should submit (and what to keep optional)

The fastest way to make people hate an expense tool is to ask for a full “expense report” every time. A better pattern is: employees add individual expenses (one receipt = one line item), and the app rolls them up into a report automatically for a week, a trip, or a month. Managers approve the report, but can still open any line item when something looks off.

For each expense line, keep required fields tight so submissions take under a minute:

• Date of purchase
• Merchant
• Amount
• Currency
• Category (meals, lodging, taxi, supplies, etc.)

Everything else should be optional at first, but available when teams need it. Sales may want a client name. Operations may care about cost center. If you make those mandatory for everyone, you get fake data (“N/A”, “misc”) that finance can’t use.

Optional fields that often pay off later include project or job code, client, cost center, and payment method (personal card vs corporate card). If you’re using AppMaster, you can start with the basics and add fields later without breaking the flow, since the app can be regenerated as requirements change.

Receipt photos are the core, but the rule doesn’t need to be one-size-fits-all. Two simple policies cover most companies:

• Always required for certain categories (like lodging and airfare)
• Required only above a set amount (for example, any expense over $25)

Also allow “missing receipt” with a short reason, but limit it. That keeps the workflow moving while still giving finance control.

A clear workflow from submission to reimbursement

A good expense flow feels boring in the best way. Employees know what to do, managers can decide quickly, and finance can close the month without chasing people.

Decide where an “expense” lives. Most teams do best when expenses live inside a report (trip, month, project) so people submit in batches instead of one-off items.

The employee flow should be: create a report, add one expense at a time, snap or upload the receipt, and submit when everything is ready. Keep the form short so the receipt photo does most of the explaining.

Once submitted, managers should have three clear actions: approve, reject, or request clarification. “Request clarification” is the key to fewer re-submissions. It should send a simple question back to the employee and keep the report intact so they only fix what’s missing.

Finance should do a second pass, but not on everything. Use spot checks for high amounts, certain categories, or missing fields. Finance can enforce policy and do the final approval before reimbursement is marked paid.

Make statuses visible everywhere, not buried in a log. Four stages are usually enough:

• Draft (only the employee sees it)
• Submitted (waiting on manager)
• Approved (manager and finance complete)
• Paid (reimbursement done)

If you build this in AppMaster, keep the workflow logic in one place (a single business process) so status changes, notifications, and permissions stay consistent across web and mobile screens.

Screens to design first (keep them minimal)

Most expense apps win or lose on the first few screens. Keep them small, fast, and focused on one job each. You can add polish later, but if the basics feel slow, people stop using it.

Employee (mobile): submit in under a minute

Start with a “New expense” flow that works when someone is in a taxi or airport line. Let them snap a photo, enter the amount, pick a category, and save a draft if they’re missing details.

Aim for these essentials on day one:

• New expense form (merchant, date, amount, category)
• Camera upload with a clear “retake” option
• Drafts list (so nothing is lost mid-trip)
• Status view (so they don’t guess)
• Notes field (optional)

Manager: approve without opening every receipt

Managers need a queue that answers “what needs my attention today?” Add simple filters (team, date range, over-policy) and make approve or reject one tap. Comments should be quick, and ideally suggested, like “Please add project code” or “Need itemized receipt.”

Keep notifications selective: one when an expense is submitted (or when a weekly batch arrives), and one when it’s approved or needs changes. Avoid pinging on every small edit to a draft.

Finance: close the month, not chase people

Finance needs a monthly view with totals by person, cost center, and category, plus an exceptions list for missing fields or policy issues. If you’re building in AppMaster, design the export screen around how your team closes the month: one period selector, a review table, and a single export action after exceptions are cleared.

Data model that stays tidy as you grow

A good data model is what keeps the app feeling simple months later, when you have more employees, more policies, and more edge cases. Keep the core entities small and predictable, then add optional fields only when you really need them.

Start with a few tables that map to how people actually work:

• Users: roles plus cost center or team.
• Reports: one per trip or month, owned by a user, with a status (Draft, Submitted, Approved, Paid).
• Expenses: line items inside a report (date, merchant, amount, currency, category, notes).
• ReceiptFiles: file records tied to an expense (filename, size, MIME type, storage key).
• Approvals: one row per approval step (who, what decision, when).

Keep relationships strict: one report has many expenses, and one expense can have many receipt files (useful when someone uploads two pages or a corrected photo). Avoid putting receipt data directly on the expense row. Store the photo as a file and keep only the metadata and pointer in your database.

Treat receipt photos as private by default. Store access rules with the expense: only the employee, assigned approver(s), and finance should be able to view or download.

Add an audit trail that answers “who did what, and when” without guesswork. In AppMaster, you can model this in PostgreSQL using the Data Designer and include fields like submitted_by, approved_by, created_at, updated_at, decision_at, and a short comment for each decision.

Approvals and policy checks that reduce back-and-forth

Most delays happen when someone submits an expense and the reviewer has to ask three follow-up questions. The fix is simple: make rules clear and run quick checks the moment an employee taps Submit.

Start with a few policy rules everyone understands. Keep them visible so employees don’t feel surprised later. Rules that prevent most rework:

• Category limits (for example, taxis up to a set amount per ride)
• Daily meal caps (breakfast, lunch, dinner)
• Receipt required above a threshold amount
• Allowed dates (no future dates, and usually no claims older than X days)
• Duplicate detection (same merchant, date, and amount)

Run these checks at submit time. If something is missing, say exactly what to fix. “Receipt is required for amounts over $25” beats “Validation failed.” Also block obvious errors like negative amounts or missing currency.

Not every issue should be a hard stop. For exceptions, allow submission but flag it clearly for review. Example: a traveler won’t get the hotel receipt until the next morning. Let them submit without the receipt, mark it “Receipt pending,” and route it to finance after manager approval.

Approval routing should match how money is owned in your company. Some teams need only a direct manager. Others need a cost center owner for bigger spends, then finance for a final check. In AppMaster, you can model routing as a decision flow in the Business Process Editor so the app follows the right path without manual chasing.

One detail that helps: include a “Send back with note” option and require a comment. That keeps the conversation inside the claim instead of scattered across email and chat.

Finance exports that match how your team closes the month

Finance usually doesn’t want “an app report.” They want a file that fits the monthly close routine they already trust, with clean columns and totals they can tie out.

Agree on what totals finance needs every month: by employee, category, cost center, and project. Export both detailed line items and a summary so finance can audit a spike without asking for screenshots.

Keep the export format boring on purpose. A CSV with consistent column names prevents copy-paste fixes. Columns that save time:

• Month (YYYY-MM)
• Employee ID or email
• Category
• Cost center and project code
• Amount (original), currency, and amount (home currency)

Multi-currency is where exports often break. Store the original amount and currency exactly as submitted, plus a converted amount for reporting. Store the exchange rate and the date used so finance can explain differences later (for example, “rate on receipt date” vs “rate on reimbursement date”).

Treat month-end like a close. Once finance exports March, March shouldn’t change. Add a month lock that blocks edits to approved expenses in that period (or forces a correction entry in the next month). A short close checklist helps:

• All pending approvals resolved
• Export generated and saved
• Month locked
• Late receipts entered as next-month adjustments

In AppMaster, this maps cleanly to a status field, a close flag on the period, and a business process that blocks edits when the month is locked.

Common mistakes that make expense apps frustrating

Most expense tools fail for simple reasons: people can’t submit clean evidence fast, managers don’t know what to do next, and finance gets messy data at month-end.

Receipt photos are the first tripwire. A dark restaurant receipt, a cropped total, or a foreign currency without context can turn a 30-second task into a week of messages. Add a quick preview step so employees can see what the manager will see, and prompt for a retake when the total or date isn’t readable.

Duplicates are the second tripwire. The common pattern is: someone submits from their phone, then submits again from their laptop because they’re unsure it worked. You don’t need complex rules to catch most of these. Flag likely duplicates using a simple match like merchant + date + amount, and ask the employee to confirm which one to keep.

Approval bottlenecks usually come from unclear ownership. If an expense sits in limbo, it’s often because no one knows who approves it, or the workflow has too many steps for small amounts.

Mistakes to avoid (and what to do instead)

• Too many categories: start with a short list (travel, meals, lodging, mileage, other) and let finance map later.
• Too many required fields: require only what policy truly needs (amount, date, merchant, receipt).
• No reminders: send a nudge after 2-3 days to the right approver.
• One-size approvals: auto-approve low amounts, escalate only when needed.
• No currency clarity: store currency per receipt and show the exchange-rate basis if you convert.

If you build this in AppMaster, keep the rules visible in the workflow so you can adjust them when policy changes without rebuilding everything.

Quick checks before you roll it out

Before you invite the whole company, run a short pilot with 5 to 10 people (one frequent traveler, one manager who approves often, and someone in finance). The goal is to confirm the basic flow is fast, clear, and hard to mess up.

A timing test tells you a lot. If an employee can’t finish a normal claim quickly, they’ll save receipts for later and the paperwork pile comes back. If managers can’t approve on a phone between meetings, approvals stall.

Checklist for rollout readiness:

• An employee can submit a claim (1 receipt, tip included, notes optional) in under 60 seconds.
• A manager can open, review, and approve from a phone in under 30 seconds.
• Every expense is tied to a report, and every report has a clear approver (no orphan items).
• Finance can export one full month in a single step, and totals match without manual cleanup.
• Receipts are stored, searchable, and attached to the right expense every time.

Run one realistic scenario end to end: “Taxi receipt submitted today, approved tomorrow, included in this month’s export.” If anything is unclear, fix screen text and defaults before adding more features.

If you’re building this in AppMaster, keep the pilot focused on speed and clarity first. You can add extra policy checks later, but a slow first experience is hard to recover from.

Example: one trip, three receipts, and a smooth month-end

Maya goes on a two-day customer visit. She uses the app on her phone as she goes, so nothing piles up.

On day one, she uploads a taxi receipt for $28 and snaps a photo of the hotel invoice for $412. The app reads the vendor and amount from the photo, but Maya can quickly correct it if the scan is messy.

At dinner, she forgets to ask for a receipt. She still submits the meal as a manual entry for $34 and marks it “receipt missing” with a short note: “Restaurant printer down, paid by card.” The flow keeps moving without hiding the issue.

Her manager, Jordan, reviews the report the next morning. Jordan approves the taxi and hotel in one tap, then taps “Need info” on the meal and asks: “Was this with a customer? Add names.” Maya replies in the claim, adds attendees, and Jordan approves it.

Finance reviews everything before reimbursement. They notice the meal is above policy for that city by $6, so they flag it as an exception but don’t block month-end. The report is reimbursed, and the exception is tracked for coaching.

At the end of the month, finance exports totals that match how they close. A practical export often includes:

• Employee, department, and cost center
• Date, merchant, and category
• Amount, tax, and currency
• Receipt status (attached, missing, unreadable)
• Approval and exception flags

Month-end looks like “Travel: $440,” “Meals: $34,” and “Exceptions: 1,” with receipt images available if an auditor asks later. If you build this in AppMaster, it’s easier to adjust the workflow and export fields when policy changes.

Next steps: pilot, measure, and build it in a way you can change

Start small on purpose. Pick a pilot group that creates enough real receipts to test the flow, but not so many that fixes become painful.

Give the pilot a one-page cheat sheet that answers the daily questions: what needs a receipt, what’s allowed without one, what categories to use, and how quickly managers are expected to approve. If people can’t find the rule in 10 seconds, they’ll guess.

Pilot setup checklist:

• Choose 10-30 employees across different roles and locations
• Set a clear start date and a 2-4 week test window
• Define who approves and who exports month-end totals
• Decide what happens when a claim is rejected (edit and resubmit, or new claim)
• Create one shared place to report issues and policy questions

While the pilot runs, measure a few numbers that show where friction is:

• Average time to submit (from opening the app to sending)
• Average approval time (submission to manager decision)
• Exception rate (missing receipt, wrong category, over limit)
• Rework rate (sent back for edits)

After 2-4 weeks, adjust categories, limits, and notifications based on the data, not opinions. If meals cause most exceptions, add a short hint on what’s required, or split it into “Client meals” and “Team meals.”

Build it so change is easy. Expense policies evolve, teams grow, and finance will ask for new export fields. If you want to move fast without heavy coding, AppMaster lets you build the full workflow (backend, web, and mobile), then deploy to the cloud you already use or export the source code for self-hosting. When requirements shift, you update the logic and regenerate the app instead of stacking workarounds.

If you want to explore the approach, appmaster.io is a practical place to start for teams that want a no-code build but still need production-ready apps with real backend logic.