Real-world scenarios

Overview

This article walks through two scenarios drawn from real reconciliation work: a general ledger reconciliation on a single cash account, and a bank statement reconciliation handed to the worker with nothing more than a one-line email instruction.

Scenario: General Ledger Account Reconciliation

A finance user hands the Reconciliation Manager one cash account, one accounting period, and a list of unmatched transactions. The instruction is plain language: one account, one year, one period. There is no form to fill in and no rules to configure.

Step 1: Ledger Transactions Read and Compared

The Reconciliation Manager reads the ledger transactions for the account and compares them field by field.

Step 2: Transactions Grouped

Transactions that belong together are grouped. Each group pairs a debit against a credit.

Step 3: Evidence Shown for Every Group

The last column of every group shows exactly why the transactions were matched: transfer identifier, amount, voucher number, voucher date, currency, and transaction code. The evidence sits on the screen, so a reviewer does not have to trust a score on its own.

Step 4: Unmatched Items Listed with a Reason

The Reconciliation Manager also lists what it could not match, and why.

Step 5: Every Group Marked for Review

Every group, matched and unmatched, is marked for review. The Reconciliation Manager proposes; the finance user decides.

Result: A cash account that would otherwise require a person to work through every transaction by hand is grouped, evidenced, and ready for review, with the reasoning behind every group already shown.

Scenario: Bank Statement Reconciliation

Every period, someone has to prove that the bank statement and the cashbook agree, line by line. It is necessary, it is repeatable, and normally it is slow.

Step 1: Statement Emailed with a One-Line Instruction

The finance user emails the statement to the worker’s mailbox with a one-line instruction. No form, no configuration.

Step 2: Statement Loaded into IFS Cloud

The Reconciliation Manager picks up the mail and loads the statement into IFS Cloud.

Step 3: Automatic Matching Runs

The worker runs automatic matching against the cash transactions on the account.

Step 4: Result Reported Back

Under a minute later, it reports back: the statement loaded without errors, and every bank transaction matched a cash transaction.

Step 5: Reconciliation Created with a Direct Link

A reconciliation is created with its own identifier, and the Reconciliation Manager hands over a direct link rather than leaving the finance user to go find it.

Result: A task that normally takes a person a meaningful chunk of the close, downloading the statement, matching it line by line, and tracking down the record afterward, is completed and handed back with a direct link in under a minute.

What These Scenarios Illustrate

Plain language is enough to start. Neither scenario requires a form or a rules configuration step. One account, one period, and an instruction in ordinary language is sufficient for the Reconciliation Manager to begin work.

Evidence sits with the match, not behind it. In both scenarios, the reason a group of transactions was matched, or a statement line was cleared, is shown directly rather than left for a reviewer to take on trust.

The worker proposes; the person decides. Every group in the general ledger scenario is marked for review. The Reconciliation Manager does not close anything on its own judgement; it presents its groupings and its reasoning, and the finance user makes the call.

Clean results are reported plainly. In the bank statement scenario, a fully matched statement produces a short, direct report and a link, not a lengthy walkthrough. The system scales its output to the complexity of the result.

The same underlying process handles both account types. Whether the input is a list of ledger transactions or an emailed bank statement, the worker follows the same shape: read, compare, group or match, evidence, and hand off for review.