Skip to content

Home » Proiecte » Expense claims app: from a photographed receipt to the accounts

Typical project

Expense claims app: from a photographed receipt to the accounts

What goes into an app where field staff photograph their receipts, the data is extracted and sorted into categories, the manager approves and the accountant receives the export.

The sales rep comes back from a trip with an envelope of receipts: fuel, parking, a meal with a business partner. The rep sticks them on a sheet of paper, fills in a form, leaves it on the manager’s desk and waits. Today’s version is called, for short, an expense claims app: the same person photographs the receipt in the car park, and the rest of the process runs without paper being carried around the company.

The people who gain most are usually two: the employee, who gets their money back sooner, and the person in accounting who would otherwise be deciphering faded receipts at the end of the month.

The thermal receipt, the envelope and the end of the month

Thermal paper fades. A receipt kept in the glovebox for a month is often illegible on exactly the line with the amount. Other receipts get lost. And when all the claims arrive in the last days of the month, approval becomes a formality, because nobody has time to look.

Then there is the question every new employee asks: what am I allowed to claim? If the answer sits in a policy document nobody has read, the result is rejected expenses and awkward conversations. A good app tells people the rule at the moment they enter the expense.

What happens between the photo and getting the money back

The employee photographs the document and, where relevant, chooses the trip or project it belongs to. The image goes through optical character recognition (OCR, that is, automatic reading of the text in a picture), and the app suggests the date, the amount and the merchant. The employee checks, corrects anything that is wrong and submits.

The approver does not receive a stack of paper but a list to go through on their phone. They can approve everything, reject a single expense with a reason, or ask for clarification.

  • Capture: a photo taken in the app or a file received by email.
  • Data extraction: amount, date, issuer, with uncertain values highlighted for checking.
  • Category: fuel, accommodation, transport, business entertainment and whatever other categories you use.
  • The claim: the expenses from one trip gathered into a single document, from which the advance received is deducted.
  • Payment: the list of amounts to be reimbursed, ready for whoever makes the payments.

Company rules, written into the app and not into a forgotten policy

Every company has its own ways: which categories exist, who approves whom, which expenses need a written justification, above what value a second approval is required. Your administrator configures all of it, without a developer. You choose the values, together with your accountant; the app does not come with preset limits.

When an expense falls outside the rules, the app does not necessarily block it. It flags it and asks for an explanation. A technician stays overnight in a town where that was not planned: the accommodation shows up as an exception, the technician writes the reason, and the manager approves in full knowledge of the facts.

There is one limit we state plainly: the app does not decide the tax treatment. Whether an expense is deductible, to what extent and with which documents is for the accountant to determine. The app gives them the information in good order, so that they can decide quickly.

An expense claims app on the phone: in the browser, no app store

More often than not we recommend a progressive web app: a website that behaves like an app, can be added to the phone’s home screen, uses the camera and runs on both Android and iPhone, with no need to publish it in the app stores. There are differences between the two systems (in notifications and in working without a signal), which we test on the team’s own phones. If your people often work in areas with no signal, we discuss saving expenses locally and sending them when the app is next opened with a signal.

We usually write the server side in Laravel. Data extraction can use OCR engines installed on your own server or services that specialise in receipts and invoices; the choice depends on the results with your real documents and on where you are willing to have the images processed. Accounting is sent an export in the format required by the accountant’s software.

How you can tell the app is doing its job

Most often, a project like this stumbles over adoption, not technology. If the app takes more steps than the paper form, people go back to the envelope. That is why we test the first versions with two or three field employees, on their own phones, and keep shortening the process until entering a receipt means taking the photo and a quick check.

Whether the original receipts still have to be kept after they have been photographed is a question for the accountant, and their answer goes into the instructions in the app. The rest shows in the data.

  • Time to entry: how quickly an expense gets into the app.
  • Approval time: where claims are waiting and with whom.
  • Manual corrections: how much of what the automatic reading suggests has to be changed.

Frequently asked questions

Does the app read every receipt correctly?

No. Receipts that are crumpled, faded or photographed in the dark are read poorly, and handwritten documents hardly at all. That is why the extracted data is shown as a suggestion, and the employee confirms it before submitting.

Can it be connected to payroll or accounting software?

Yes, through export files or, if the software in question has a programming interface, directly. Which fields are sent and in what format is agreed with the accountant, according to the software they use.

Is a custom app worth it for a small team?

For a few people who rarely travel, an off-the-shelf product on subscription is usually the better choice. Custom development is justified when your approval rules are out of the ordinary or when the data has to reach software that standard products do not know about.

This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.

Want a project like this?

Write us a few lines about what you want to build or what no longer works. We will reply with concrete steps and a quote with a price for each stage.

WhatsApp