How to test an expense management tool

01Direct answer

02What counts as an expense management tool

An expense management tool here means a web and mobile product that issues or controls corporate cards, captures receipts, routes reports for approval and pays reimbursements to employees. It counts when the tool stores receipt images and card data for employees of one or more customer companies. A general ledger product that only receives approved expense totals is out of scope, and so is a personal budgeting app with no employer approval chain.

Adjacent product types not covered here

• accounting and invoicing SaaS: An accounting product receives approved totals, so its risk sits in ledger postings and tax filings rather than receipt capture and card controls.
• neobank: A neobank holds the customer's primary account and carries deposit and transfer risks, while an expense tool spends an employer's money through cards it issues and freezes.

03Risk map

04Mandatory tests (9)

1. 1

   Step 1: release smoke tests

   Why:money-loss

   Done when: After each release, a test employee captures a receipt, submits a report, a manager approves it and the reimbursement appears in the payout file.

   Tool class: mobile automation. Who usually runs it: QA engineer.

2. 2

   Step 2: end-to-end functional tests

   Why:regulatory-penaltymoney-lossfraud-abuse

   Done when: A report with a missing receipt or business purpose cannot be approved for payment, and an employee leaving the company has every card frozen on the offboarding date, and a dinner split into two receipts below the approval threshold, or a card charge claimed again as out-of-pocket, is flagged before payment.

   Tool class: browser automation. Who usually runs it: QA engineer.

3. 3

   Step 3: penetration testing

   Why:data-breachmoney-lossfraud-abuse

   Done when: An external tester cannot open another team's receipts by changing an ID, and cannot raise their own card limit or approve their own report.

   Tool class: proxy. Who usually runs it: external lab.

4. 4

   Step 4: integration tests

   Why:money-lossdata-corruption

   Done when: A card transaction from the issuer processor appears once on the cardholder's expense list with the same amount, currency and merchant, and a reversal removes it.

   Tool class: API client. Who usually runs it: developer.

5. 5

   Step 5: payment and money-flow testing

   Why:money-loss

   Done when: In the card sandbox, a frozen card declines the next purchase, a merchant-category block declines a blocked purchase, and a spend limit declines the first charge above it.

   Tool class: API client. Who usually runs it: QA engineer.

6. 6

   Step 6: compliance checks

   Why:regulatory-penaltydata-corruption

   Done when: A reviewer finds, for a sample of reimbursements, the receipt, the business purpose, the approver and any returned advance recorded with dates.

   Tool class: test management. Who usually runs it: product manager.

7. 7

   Step 7: unit tests

   Why:data-corruption

   Done when: Currency conversion, per diem and mileage amounts match a reviewed table for each rate and country the tool supports.

   Tool class: unit framework. Who usually runs it: developer.

8. 8

   Step 8: security scanning

   Why:data-breach

   Done when: The latest scan of the web app, mobile API and receipt storage shows no open finding that exposes receipt images or card numbers.

   Tool class: DAST scanner. Who usually runs it: security specialist.

9. 9

   Step 9: data integrity and migration testing

   Why:data-corruption

   Done when: For a sample of approved expenses, each stored receipt image opens, shows a readable amount and date, and is linked to the same expense line after edits.

   Tool class: data validation. Who usually runs it: QA engineer.

05Recommended and optional tests

• regression suiterecommended

  Becomes mandatory when customers configure their own approval chains.

• device and browser compatibilityrecommended

  Becomes mandatory when receipt capture moves to a new camera or image pipeline.

• accessibility testingrecommended

  Becomes mandatory when a customer contract or the EU Accessibility Act requires it.

• offline and poor-network testingrecommended

  Becomes mandatory when lost or duplicate receipts appear in support tickets.

• exploratory testingoptional

  Sessions around split expenses, mixed personal and business charges and refunds on a corporate card may find states scripted cases miss.

• resilience and failure testingoptional

  If the card processor is unavailable, card controls may not apply; a test shows how the tool behaves.

06Not needed and why

• usability testing

  Not needed for risk control: no attached risk depends on comprehension testing. Becomes recommended when report completion rate is a tracked goal.

• performance and load testing

  Not needed: no outage under load is recorded for this type. Becomes recommended when month-end report submission produces a recorded slowdown.

• localization testing

  Not needed while every employee submits expenses in one language. Becomes recommended when expense forms or receipts ship in a second language.

07Order of work

08Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of expense management tool (web, ios, android). Not recommendations.

09What to send to the person who will test

Send the checklist and the brief below. The printable checklist for expense management tool has the same 9 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the expense management tool is accepted when a report without a receipt or business purpose cannot be approved for payment and an offboarded employee's cards decline the next purchase. Card transactions from the issuer processor appear once on the cardholder's list with matching amount, currency and merchant, and each stored receipt image opens readable and linked to its expense line. No open scan finding exposes receipt images or card numbers.

Brief

# Test brief: expense management tool

Product type: expense management tool. Corporate cards, receipts, approvals and reimbursements.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/expense-management/
Printable checklist: https://howtotestaproduct.com/checklists/expense-management/

Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: money-loss). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: After each release, a test employee captures a receipt, submits a report, a manager approves it and the reimbursement appears in the payout file.
2. end-to-end functional tests (risks: regulatory-penalty, money-loss, fraud-abuse). Tool class: browser automation. Usually run by: QA engineer.
   Done when: A report with a missing receipt or business purpose cannot be approved for payment, and an employee leaving the company has every card frozen on the offboarding date, and a dinner split into two receipts below the approval threshold, or a card charge claimed again as out-of-pocket, is flagged before payment.
3. penetration testing (risks: data-breach, money-loss, fraud-abuse). Tool class: proxy. Usually run by: external lab.
   Done when: An external tester cannot open another team's receipts by changing an ID, and cannot raise their own card limit or approve their own report.
4. integration tests (risks: money-loss, data-corruption). Tool class: API client. Usually run by: developer.
   Done when: A card transaction from the issuer processor appears once on the cardholder's expense list with the same amount, currency and merchant, and a reversal removes it.
5. payment and money-flow testing (risks: money-loss). Tool class: API client. Usually run by: QA engineer.
   Done when: In the card sandbox, a frozen card declines the next purchase, a merchant-category block declines a blocked purchase, and a spend limit declines the first charge above it.
6. compliance checks (risks: regulatory-penalty, data-corruption). Tool class: test management. Usually run by: product manager.
   Done when: A reviewer finds, for a sample of reimbursements, the receipt, the business purpose, the approver and any returned advance recorded with dates.
7. unit tests (risks: data-corruption). Tool class: unit framework. Usually run by: developer.
   Done when: Currency conversion, per diem and mileage amounts match a reviewed table for each rate and country the tool supports.
8. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: The latest scan of the web app, mobile API and receipt storage shows no open finding that exposes receipt images or card numbers.
9. data integrity and migration testing (risks: data-corruption). Tool class: data validation. Usually run by: QA engineer.
   Done when: For a sample of approved expenses, each stored receipt image opens, shows a readable amount and date, and is linked to the same expense line after edits.

Acceptance criteria wording:
A release of the expense management tool is accepted when a report without a receipt or business purpose cannot be approved for payment and an offboarded employee's cards decline the next purchase. Card transactions from the issuer processor appear once on the cardholder's list with matching amount, currency and merchant, and each stored receipt image opens readable and linked to its expense line. No open scan finding exposes receipt images or card numbers.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

10Questions about testing an expense management tool

11Evidence

1. ev-0084vendor-docsecondary

   Occupational Fraud 2026: A Report to the Nations, Association of Certified Fraud Examiners

   Expense reimbursements scheme: A fraudulent disbursement scheme in which an employee makes a claim for reimbursement of fictitious or inflated business expenses

   Supports fraud-abuse for an expense management tool and accounting SaaS: the survey-based industry report with stated method tracks expense reimbursement schemes, which its Fraud Tree splits into mischaracterized, overstated, fictitious and multiple reimbursements, and billing schemes (fictitious or inflated invoices paid through payables) as recurring occupational fraud types.

   published undated · verified 2026-10-07

2. ev-0083regulatorprimary

   § 1026.12 Special credit card provisions., Consumer Financial Protection Bureau

   General requirement for money-loss on an expense management tool that issues corporate cards: the consumer cap on unauthorized-use liability can be contracted away for employee card programs, so spend on a lost or misused employee card can fall on the company.

   published undated · verified 2026-10-07

3. ev-0082regulatorprimary

   Publication 463 (2025), Travel, Gift, and Car Expenses, Internal Revenue Service

   Supports regulatory-penalty for an expense management tool: reimbursements count as an accountable plan only with adequate accounting, documentary evidence such as receipts and return of excess advances; otherwise the employer reports them as wages.

   published undated · verified 2026-10-07

4. ev-0010standardprimary

   PCI DSS document library, PCI Security Standards Council

   PCI DSS sets security requirements, including vulnerability scanning and penetration testing, for any system that stores, processes or transmits cardholder data.

   published undated · verified 2026-10-07

5. ev-0012standardprimary

   OWASP API Security Top 10 2023, OWASP Foundation

   The API Security Top 10 names API-specific failures such as broken object level authorization and unrestricted resource consumption.

   published undated · verified 2026-10-07

6. ev-0044regulatorprimary

   Rev. Proc. 97-22: Books and records; electronic storage; imaging (Internal Revenue Bulletin 1997-13), Internal Revenue Service

   All books and records reproduced by the electronic storage system must exhibit a high degree of legibility and readability when displayed on a video display terminal and when reproduced in hardcopy.

   Supports data-corruption for accounting SaaS and expense management: taxpayers who keep books, invoices or receipt images in an electronic system need controls against alteration or deletion and legible reproductions, which both product types hold for their customers.

   published 1997-03-31 · verified 2026-10-07

12Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.