How to test an accounting and invoicing SaaS
Direct answer
Shipped untested, an accounting and invoicing SaaS lets a staff user add a supplier, enter bills for services never rendered and slip them into the next payment run, and files VAT returns through a spreadsheet re-key step or without the fraud prevention headers the tax authority API requires. 10 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with penetration testing: a guessed weak password or a changed organisation ID opens a company ledger with payroll and tax figures that can be used to file a fraudulent return.
10 mandatory testsfirst: penetration testing
What counts as an accounting and invoicing SaaS
An accounting and invoicing SaaS here is a web app and public API for small-business bookkeeping, invoicing, bank feed reconciliation, bill payments and VAT or sales tax returns, shared between owners and their accountants. It covers bank feed imports through an aggregator, tax calculation on invoice lines, payables approvals, the audit log and submissions to a tax authority API. Payroll processing, corporate card and receipt tools and invoice pay-now links that collect money are out of scope.
Adjacent product types not covered here
- expense management tool: An expense management tool runs corporate cards, receipts and reimbursements, so split receipts and cards left active after offboarding replace bank feed duplicates and VAT submissions.
- insurance app: An insurance app prices consumer policies from filed rates, so rating data loads and licence number exposure replace bill approval fraud and bank feed outages.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Fraud or abuse by users fraud-abuse | money | secondary | A staff user adds a supplier, enters bills for services never rendered and marks them for the next payment run, and the owner approves the batch total. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | The VAT return needs a spreadsheet export and re-key step, breaking the digital link rule, or the submission API call lacks the required fraud prevention headers. | |
| Personal or sensitive data exposed data-breach | data | primary | An attacker guesses a weak password on a company ledger, downloads payroll and tax figures, and files a fraudulent tax return in the business's name. | |
| Records silently wrong data-corruption | data | primary | A bank feed re-imports transactions after a provider outage, and the duplicates sit in the books until removed by hand before reconciling; and ledger entries edited or deleted afterwards leave no trace. | |
| Third-party dependency fails dependency-failure | outage | practitioner single incident, no second source | The open banking provider goes down, and bank feed imports stop until it recovers. |
Mandatory tests (10)
Step 1: release smoke tests
Why:data-corruption
Done when: After each release, a test company creates and sends an invoice, records the payment and sees the trial balance still in balance.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 2: penetration testing
Done when: An external tester cannot log in by guessing common passwords, and cannot read another company's ledger by changing an organisation ID.
Tool class: proxy. Who usually runs it: external lab.
Step 3: end-to-end functional tests
Why:fraud-abuse
Done when: A bill entered by a user for a supplier that same user created cannot be paid until a second user approves it.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 4: data integrity and migration testing
Why:data-corruptionregulatory-penalty
Done when: Importing the same bank statement twice leaves one copy of each transaction, and the VAT report totals equal the sum of the posted ledger lines.
Tool class: data validation. Who usually runs it: QA engineer.
Step 5: compliance checks
Why:regulatory-penaltydata-corruption
Done when: A reviewer traces a filed VAT return back to ledger entries with no manual export step, and finds edited or deleted entries kept in the audit log.
Tool class: test management. Who usually runs it: product manager.
Step 6: contract tests
Done when: Each VAT return submission in the tax authority sandbox is accepted, and the fraud prevention header check reports no missing field.
Tool class: contract tool. Who usually runs it: developer.
Step 7: integration tests
Why:dependency-failuredata-corruption
Done when: A transaction posted in the sandbox bank appears once in the bank feed with the same date, amount and payee.
Tool class: API client. Who usually runs it: developer.
Step 8: unit tests
Why:data-corruption
Done when: VAT, sales tax and rounding on invoice lines match a reviewed table for each tax rate and currency offered, including credit notes.
Tool class: unit framework. Who usually runs it: developer.
Step 9: security scanning
Why:data-breach
Done when: The latest scan of the web app and public API shows no open finding that exposes another company's ledger or payroll data.
Tool class: DAST scanner. Who usually runs it: security specialist.
Step 10: resilience and failure testing
Done when: When the bank feed provider is cut off in a test environment, the account shows a visible stale-feed warning, and the catch-up import after recovery creates no duplicates.
Tool class: chaos tool. Who usually runs it: developer.
Recommended and optional tests
regression suiterecommended
Becomes mandatory when tax rules or chart-of-accounts logic change in a release.
accessibility testingrecommended
Becomes mandatory when public-sector customers or an accessibility complaint require it.
localization testingrecommended
Becomes mandatory when a second tax jurisdiction is supported.
payment and money-flow testingrecommended
Becomes mandatory when invoices carry a pay-now link that collects money through the product.
exploratory testingoptional
Sessions around year-end close, locked periods and backdated entries may find ledger states scripted cases miss.
Not needed and why
Not needed for risk control: no attached risk depends on comprehension testing. Becomes recommended when onboarding of non-accountant owners is a tracked goal.
Not needed: no outage under load is recorded for this type. Becomes recommended when a filing deadline produces a recorded slowdown or outage.
device and browser compatibility
Not needed: the product is a web app on current desktop browsers. Becomes recommended when a mobile receipt or invoice app ships.
Order of work
First release
- release smoke tests: As a test company, create and send an invoice, record the payment and confirm the trial balance still balances.
- penetration testing: Have an external tester try common passwords on test company logins and change the organisation ID to read another company's ledger.
- end-to-end functional tests: Have one user create a supplier and enter a bill for it, then confirm the bill cannot be paid until a second user approves it.
- data integrity and migration testing: Import the same bank statement twice and confirm one copy of each transaction remains and the VAT report totals equal the posted ledger lines.
- compliance checks: Trace a filed test VAT return back to ledger entries with no manual export step and confirm edited and deleted entries remain in the audit log.
- contract tests: Submit a VAT return in the tax authority sandbox and confirm it is accepted and the fraud prevention header check reports no missing field.
- integration tests: Post a transaction in the sandbox bank and confirm it appears once in the bank feed with the same date, amount and payee.
- unit tests: Run VAT, sales tax and rounding on invoice lines against the reviewed table for each tax rate and currency offered, including credit notes.
- security scanning: Scan the web app and public API and close every finding that exposes another company's ledger or payroll data.
- resilience and failure testing: Cut off the bank feed provider in a test environment, confirm the stale-feed warning on the account and confirm the catch-up import after recovery creates no duplicates.
Ongoing cadence
- release smoke tests: After every release to customers with live books.
- contract tests: When the tax authority changes its API version or fraud prevention header rules.
- unit tests: When a tax rate, currency or rounding rule is added or changed.
- data integrity and migration testing: After each change to bank feed import or de-duplication logic.
- integration tests: When the bank feed aggregator or a bank API changes version.
- resilience and failure testing: After each bank feed provider outage and before each switch of aggregator.
- regression suite: On every release that changes tax rules or chart-of-accounts logic.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of accounting and invoicing SaaS (web, api). Not recommendations.
release smoke tests
penetration testing
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
end-to-end functional tests
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DeepEvalUnit-style evaluation for LLM applications. apiopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
data integrity and migration testing
- dbt testsTests on warehouse models inside dbt. apiopen-source
- Great ExpectationsData validation with declarative expectations. apiopen-source
contract tests
- PactConsumer-driven contract testing with a broker. apiopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- pytestTest framework for Python with fixtures and plugins. apiopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
unit tests
security scanning
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
- GarakProbing LLM applications for prompt injection and leakage. apiopen-source
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- OWASP ZAPDynamic application security scanner. webapiopen-source
- SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source
- SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
- SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
- TrivyScanner for containers, dependencies and configuration. apiopen-source
resilience and failure testing
- Chaos MeshFault injection for Kubernetes. apiopen-source
- GremlinManaged fault injection. apicommercial
- ToxiproxyTCP proxy for simulating network failures. apiopen-source
regression suite
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DeepEvalUnit-style evaluation for LLM applications. apiopen-source
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
accessibility testing
- axe-coreAccessibility rules engine for automated checks. webopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- Pa11yCommand-line accessibility testing. webopen-source
localization testing
- Lokalise QATranslation management with in-context review. webiosandroidcommercial
payment and money-flow testing
- Adyen test environmentTest cards and scenarios for Adyen integrations. webapiiosandroidcommercial
- Stripe test modeTest cards and scenarios for Stripe integrations. webapiiosandroidfreemium
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for accounting and invoicing SaaS has the same 10 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the accounting and invoicing SaaS is accepted when a test company can send an invoice, record its payment and keep the trial balance in balance. Importing the same bank statement twice leaves one copy of each transaction, and the VAT report totals equal the posted ledger lines. A VAT return submitted in the tax authority sandbox is accepted with no missing fraud prevention header field.
Brief
# Test brief: accounting and invoicing SaaS Product type: accounting and invoicing SaaS. Bookkeeping, invoicing and tax reports for small businesses. Risk map and evidence: https://howtotestaproduct.com/how-to-test/accounting-saas/ Printable checklist: https://howtotestaproduct.com/checklists/accounting-saas/ Run these 10 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: data-corruption). Tool class: browser automation. Usually run by: QA engineer. Done when: After each release, a test company creates and sends an invoice, records the payment and sees the trial balance still in balance. 2. penetration testing (risks: data-breach, fraud-abuse). Tool class: proxy. Usually run by: external lab. Done when: An external tester cannot log in by guessing common passwords, and cannot read another company's ledger by changing an organisation ID. 3. end-to-end functional tests (risks: fraud-abuse). Tool class: browser automation. Usually run by: QA engineer. Done when: A bill entered by a user for a supplier that same user created cannot be paid until a second user approves it. 4. data integrity and migration testing (risks: data-corruption, regulatory-penalty). Tool class: data validation. Usually run by: QA engineer. Done when: Importing the same bank statement twice leaves one copy of each transaction, and the VAT report totals equal the sum of the posted ledger lines. 5. compliance checks (risks: regulatory-penalty, data-corruption). Tool class: test management. Usually run by: product manager. Done when: A reviewer traces a filed VAT return back to ledger entries with no manual export step, and finds edited or deleted entries kept in the audit log. 6. contract tests (risks: regulatory-penalty). Tool class: contract tool. Usually run by: developer. Done when: Each VAT return submission in the tax authority sandbox is accepted, and the fraud prevention header check reports no missing field. 7. integration tests (risks: dependency-failure, data-corruption). Tool class: API client. Usually run by: developer. Done when: A transaction posted in the sandbox bank appears once in the bank feed with the same date, amount and payee. 8. unit tests (risks: data-corruption). Tool class: unit framework. Usually run by: developer. Done when: VAT, sales tax and rounding on invoice lines match a reviewed table for each tax rate and currency offered, including credit notes. 9. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: The latest scan of the web app and public API shows no open finding that exposes another company's ledger or payroll data. 10. resilience and failure testing (risks: dependency-failure). Tool class: chaos tool. Usually run by: developer. Done when: When the bank feed provider is cut off in a test environment, the account shows a visible stale-feed warning, and the catch-up import after recovery creates no duplicates. Acceptance criteria wording: A release of the accounting and invoicing SaaS is accepted when a test company can send an invoice, record its payment and keep the trial balance in balance. Importing the same bank statement twice leaves one copy of each transaction, and the VAT report totals equal the posted ledger lines. A VAT return submitted in the tax authority sandbox is accepted with no missing fraud prevention header field. 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.
Questions about testing an accounting and invoicing SaaS
What testing does an accounting and invoicing SaaS need?
10 tests are mandatory, from the invoice-to-trial-balance smoke test and penetration testing of company logins to VAT submission contract checks and bank feed outage tests. Each is tied to one of the 5 risks in the map, such as duplicated bank feed lines left in the books after an outage or a staff user paying bills to a supplier they created. Regression, accessibility, localization and payment sandbox tests are recommended, each with the event that makes it mandatory.
Which tests in a vendor test plan for an accounting and invoicing SaaS are not needed?
Usability testing is not needed for risk control while no attached risk depends on it, until onboarding of non-accountant owners is a tracked goal. Performance testing is not needed until a filing deadline produces a recorded slowdown or outage. Device compatibility is not needed while the product is a web app on current desktop browsers, until a mobile receipt or invoice app ships.
What is the minimum testing for an accounting and invoicing SaaS at MVP stage?
The minimum is the 10 mandatory tests, because live books, shared company logins, bank feed imports and tax calculation on invoices apply from the first customer. Contract tests on VAT submission are mandatory only while the product files returns through a tax authority API, and bill approval tests only while it runs bill payments.
When is test automation worth it for an accounting and invoicing SaaS?
Unit tests are mandatory while the product calculates tax on invoices, checking VAT, sales tax and rounding for each rate and currency, including credit notes. The regression suite becomes mandatory when tax rules or chart-of-accounts logic change in a release, comparing profit and loss and VAT totals for a fixed set of past-year books.
Evidence
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
ev-0041regulatorprimary
VAT Notice 700/22: Making Tax Digital for VAT, HM Revenue & Customs
Manually transferring data within or between software programs, products or applications (that make up functional compatible software) is not acceptable under Making Tax Digital.
Supports regulatory-penalty and data-corruption for accounting SaaS in the UK: VAT figures must flow from the ledger to the VAT return through digital links, so an export and re-key step breaks the rule and invites figure drift.
published undated · verified 2026-10-07
ev-0042regulatorprimary
VAT (MTD) End-to-End Service Guide, HM Revenue & Customs
Supports regulatory-penalty for accounting SaaS that files VAT returns: the tax authority requires sandbox API testing and valid fraud prevention header data before it issues production credentials, so filing fails without them.
published undated · verified 2026-10-07
ev-0014standardprimary
OWASP Application Security Verification Standard (ASVS), OWASP Foundation
ASVS gives testable security requirements for web applications and services, grouped by verification level.
published undated · verified 2026-10-07
ev-0043court-or-fineprimary
Operator of Online Tax Preparation Service Agrees to Settle FTC Charges That it Violated Financial Privacy and Security Rules, Federal Trade Commission
Supports data-breach for accounting SaaS that produces tax reports: attackers guessed weak passwords to take over accounts of an online tax preparation service and used the stored tax data to file fraudulent returns. The same login and stored tax data exist in small-business accounting software that prepares tax reports.
published 2017-08-29 · verified 2026-10-07
ev-0040post-mortemprimary
UK Open Banking customers unable to create or manually renew bank feeds, Xero
Supports dependency-failure and data-corruption for accounting SaaS: the vendor's own incident report says an open banking provider outage stopped bank feed imports, and transactions imported after recovery left duplicates that customers had to remove by hand before reconciling.
published 2022-12-19 · verified 2026-10-07
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
Disclaimer
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.