# Reconciliation Software Requirements Checklist

- Author: PreciseBankFlow (https://precisebankflow.com)
- Published: 2026-10-17
- Category: Choosing reconciliation software
- Canonical: https://precisebankflow.com/blog/reconciliation-software-requirements

> A reconciliation software requirements checklist: checks, evidence, permissions, retention, exports and support, with what to ask a vendor to show you.
Reconciliation software requirements are the short list of things a tool must do before you trust it with a month-end close: its checks, its evidence, who can change what, how long data stays, what you can export and what help you get. Write each one as something a vendor can demonstrate on your data, not a box to tick.

## Check requirements: what reconciliation software must test on every statement

Check requirements describe the tests the software runs before it calls an account reconciled. The minimum is three: the statement foots, each line is matched or listed as unmatched, and anything that looks wrong, such as a duplicate or a gap, is reported. A tool that skips the first test can match perfectly and still miss a line.

### The footing test

Footing means opening balance plus credits less debits equals the closing balance the bank printed. Write this as a requirement in plain words: "The tool reports any statement that does not foot, with the size of the difference, and does not adjust it." The last clause matters. Some tools force a balance with an adjusting line, which turns a missing transaction into an invisible one.

### The matching test

Matching pairs statement lines with ledger or register entries. Your requirement should state the rules you need: exact match, a date window you can set per account, an amount tolerance that is reported rather than absorbed, and one-to-many matching for batched deposits. If you are unsure which rules your data needs, [how transaction matching software pairs lines](/blog/transaction-matching-software) explains each rule and the false matches it can cause.

### The exception tests

List the exceptions your own reconciliations have produced in the past year. For most teams that includes duplicate charges, skipped check numbers, deposits recorded twice and items that sit uncleared for months. Each becomes a requirement: "The tool flags two lines with the same payee and amount within five days." Write the threshold you want; vendors will otherwise choose one for you.

## Evidence and audit trail requirements for reconciliation software

Evidence requirements describe what the software keeps so that someone who did not do the work can rely on it. A reviewer or auditor needs to see the source statement, the lines read from it, every match and the rule behind it, every manual change with its author, and the sign-off. Without that, the output is an assertion, not evidence.

### What to require

- **The original file.** The statement as uploaded, kept unchanged, linked to the reconciliation it supports.
- **Line-level source references.** Each extracted line points back to its page and position on the statement.
- **A log of edits.** Who changed an extracted amount, a match or a category, when, and from what value to what value.
- **Recorded overrides.** When a person forces a match or clears an exception, the tool keeps the reason.
- **A dated sign-off.** Preparer and reviewer names and dates, stored with the reconciliation, not in an email.

### Why auditors care

An external auditor testing cash will often reperform parts of the client's bank reconciliation and trace reconciling items to later statements. The steps of that work are set out in [audit procedures for bank reconciliation, with a program](/blog/audit-procedures-for-bank-reconciliation#substantive-procedures-for-the-bank-reconciliations-reconciling-items). If your tool keeps the evidence those procedures need, the audit asks fewer questions. If it does not, the team ends up rebuilding support from emails each year.

## Which permission and sign-off requirements matter for a small team?

Permission requirements for a small team come down to one rule: the person who prepares a reconciliation should not be the only person who approves it. Even with two people, the tool should let one prepare and the other review, and it should record both. Roles beyond that matter less than proving the separation happened.

### Minimum roles

- **Preparer.** Uploads statements, runs matching, resolves exceptions and marks the reconciliation ready.
- **Reviewer.** Reads the result, can send it back, and signs off. Cannot edit extracted amounts without the edit being logged.
- **Administrator.** Adds users and sets retention. Ideally not the same person who prepares reconciliations.

### When the team is one person

A sole bookkeeper or a small office may have no second person in finance. The requirement then changes: the tool should produce a report that an owner, board treasurer or outside accountant can review without logging in. Nonprofits with volunteer treasurers face exactly this; [reconciliation software for nonprofits and their boards](/blog/reconciliation-software-for-nonprofits) covers how to give a board reviewer what they need.

### Locking after sign-off

Require that a signed-off reconciliation is locked. Any later change should reopen it, notify the reviewer and appear in the edit log. A tool that lets anyone change a closed period quietly makes the sign-off meaningless.

## Retention, export and exit requirements in a reconciliation tool

Retention, export and exit requirements say what happens to your data over time and when you leave. Write down how long statements and reconciliations must be kept, which formats you need to export, and how you get everything out if you cancel. These requirements cost nothing to agree before signing and a great deal to fight over afterward.

### Retention

Your retention period comes from your own obligations: tax rules, audit needs, client contracts or a trust account regulator. The software should let you set a period, delete originals when it ends, and show you what it holds. Property managers holding owner and tenant funds often have the strictest rules; [reconciliation software for property management firms](/blog/reconciliation-software-for-property-management) looks at trust accounts in detail.

### Exports

Require exports a reviewer can open without the tool: a spreadsheet of extracted and matched lines, and a PDF report that shows the footing, the matches and the exceptions. An export that only another copy of the software can read does not count.

### Exit

Ask for the exit process in writing. How do you get every statement, reconciliation and log out at the end of the contract, in what format, and within how many days? Ask whether data is deleted afterward and whether the vendor confirms it.

## Support and onboarding requirements to put in writing

Support and onboarding requirements cover who helps you set the tool up, how quickly they answer when something breaks during a close, and what happens when a bank changes its statement layout. Put the answers in the contract or order form. A promise made in a sales call is not a requirement.

### Questions to settle

- Who sets up the first accounts, and is that included?
- What is the response time for a problem raised during month-end?
- How are new or changed statement layouts handled, and how fast?
- Is there a named contact, or only a shared queue?
- Is training included for new staff later, or only at the start?

For a product in early access, ask directly what is available today and what is planned. Plan your close around today's answer.

## How do you turn reconciliation requirements into a vendor demo script?

You turn reconciliation requirements into a demo script by rewriting each one as an action the vendor performs on your data while you watch. "Flags duplicates" becomes "load this statement, which has a known duplicate on page two, and show me the flag." A vendor that cannot run your script in a trial has answered the question.

### The checklist

The table below is an example checklist. Adjust the priorities and the demo actions to your own accounts.

| Requirement | Priority (example) | Ask the vendor to show you |
| --- | --- | --- |
| Statement footing reported, never adjusted | Must | Load a statement with one line deleted from the PDF and show the out-of-balance report |
| Matching with a per-account date window | Must | Set a three-day window on one account and seven on another, and show which pairs change |
| Tolerance matches listed separately | Must | Match two lines that differ by 0.03 and show where that difference is reported |
| Duplicate detection with a threshold you set | Must | Load a statement with a known double charge and show the flag |
| Check number gap detection | Should | Load a month with one missing check number and show the report |
| Edit log on extracted amounts | Must | Change one amount and show the log entry with your name and the old value |
| Preparer and reviewer separation | Must | Show a reviewer signing off and the lock that follows |
| Scanned statement reading | Should | Load your worst scan and show which lines carry a low confidence |
| Spreadsheet and PDF export | Must | Export one reconciliation and open both files outside the tool |
| Exit with all data | Must | Show the export of a full engagement or account history |
| Retention setting | Should | Show where retention is set and what is deleted at the end |

### Running the script

Send the script and the test files to each vendor before the demo. Watch them run it rather than reading slides. Mark each line pass, fail or "not shown". The vendor with the most passes on the Must lines wins, whatever the slides said.

PreciseBankFlow is built around the first lines of that table: each statement must foot, differences are listed rather than fixed, duplicates and check gaps become exceptions, and the report exports to Excel and PDF. It is opening to firms in small groups, so run the script during a trial before relying on it.

## Requirements mistake: copying a feature list instead of your own failures

The most common requirements mistake is starting from a vendor's feature list or a generic template. That produces a long list of things every tool claims and none you have tested. Start instead from the reconciliation failures your team has actually had, and make each one a requirement the tool must catch.

### Building the list from failures

Look back over a year of reconciliations. Note every time a reconciliation was wrong, late or questioned: a deposit booked twice, a statement page missing, a stale check nobody noticed, a reviewer who signed without looking. Each event points to a requirement. A missing page points to footing. A stale check points to an aging report on uncleared items. A careless sign-off points to a lock and a log.

### Keeping it short

A list of a dozen requirements tied to real failures is more useful than sixty tied to nothing. Vendors can game a long list with "yes" answers. They cannot game a short list that comes with test files.

When the list is ready, take it to a trial with your own statements. To see how PreciseBankFlow handles the footing and exception lines, [request a spot in early access](/get-started).