> For the complete documentation index, see [llms.txt](https://kb.theloops.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.theloops.io/digitalworkers/ifs-loops-digital-workers/digital-worker-guides/reconciliation-manager/core-concepts/real-world-scenarios.md).

# Real-world scenarios

## Overview&#x20;

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.&#x20;

### Scenario: General Ledger Account Reconciliation&#x20;

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.&#x20;

#### Step 1: Ledger Transactions Read and Compared&#x20;

The Reconciliation Manager reads the ledger transactions for the account and compares them field by field.&#x20;

#### Step 2: Transactions Grouped&#x20;

Transactions that belong together are grouped. Each group pairs a debit against a credit.&#x20;

#### Step 3: Evidence Shown for Every Group&#x20;

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.&#x20;

#### Step 4: Unmatched Items Listed with a Reason&#x20;

The Reconciliation Manager also lists what it could not match, and why.&#x20;

#### Step 5: Every Group Marked for Review&#x20;

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

**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.&#x20;

### Scenario: Bank Statement Reconciliation&#x20;

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.&#x20;

#### Step 1: Statement Emailed with a One-Line Instruction&#x20;

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

#### Step 2: Statement Loaded into IFS Cloud&#x20;

The Reconciliation Manager picks up the mail and loads the statement into IFS Cloud.&#x20;

#### Step 3: Automatic Matching Runs&#x20;

The worker runs automatic matching against the cash transactions on the account.&#x20;

#### Step 4: Result Reported Back&#x20;

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

#### Step 5: Reconciliation Created with a Direct Link&#x20;

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.&#x20;

**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.&#x20;

## What These Scenarios Illustrate&#x20;

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.&#x20;

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.&#x20;

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.&#x20;

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.&#x20;

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.&#x20;