# 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.