Reconciliation exceptions

A reconciliation exception is a controlled record of a difference, missing evidence or unsupported relationship that prevents a comparison from being treated as complete. Exceptions may occur inside a standard reconciliation batch item or inside the Continuous Reconciliation control plane.

Standard batch items use statuses such as pending, unmatched, discrepancy, resolved and ignored. Continuous Reconciliation introduces immutable subledger snapshots, daily comparison runs, warning or blocking severity, owner/reviewer responsibilities, due dates, escalation and independent certification.

Audience: reconciliation analysts, accountants, bursars, controllers, audit teams, implementers and support analysts
Learning time: 60 minutes
Navigation: Finance → Reconciliation and Finance → Continuous Reconciliation
Control objective: ensure every material difference has an owner, evidence, deadline, authorised decision and traceable lifecycle.

Learning outcomes

You will be able to:

• distinguish unmatched, discrepancy, ignored and continuous exceptions;
• classify a difference before attempting correction;
• explain warning versus blocking severity;
• assign owners, reviewers, due dates and escalation targets;
• operate the verified continuous exception state model;
• preserve immutable snapshot and evidence hashes;
• decide when an exception can be resolved or accepted;
• identify corrections that require P4, P5 or provider/bank action;
• prevent repeated reopening caused by unsupported fixes;
• prove readiness for run certification.

Exact definition and boundaries

Condition	Meaning	Correct response
Pending item	work has not yet reached a match decision	investigate and find evidence
Unmatched item	no acceptable internal candidate currently exists	keep open or classify discrepancy
Discrepancy item	evidence conflicts or value is unexplained	investigate and resolve
Ignored item	authorised decision that the item does not require a Payment match	retain reason; do not delete
Continuous variance exception	subledger snapshot and GL control balance differ beyond rules	assign and investigate
Missing snapshot exception	required subledger evidence was not published	restore evidence pipeline
Warning	exception is within the warning control class	resolve within policy deadline
Blocking	exception prevents certification or close under policy	urgent owner/escalation action
Resolved	preparer records a supported resolution	still awaits acceptance where required
Accepted	independent reviewer accepts the resolution	not the same as deleting history

An exception is not an “error message” to dismiss. It is a governed work item. ignored is an explicit reconciliation outcome; accepted is a review outcome; neither means the external amount ceased to exist.

Standard discrepancy decision tree

Continuous Reconciliation model

Continuous Reconciliation enrolls control accounts by domain, publishes subledger snapshots, prepares a run, compares snapshots with GL balances, creates exceptions and certifies a ready run.

Verified domains include:

• accounts_receivable;
• accounts_payable;
• payroll;
• fixed_assets;
• inventory;
• treasury;
• student_credit;
• deferred_income;
• other.

A snapshot records balance, source record count, source watermark, source system, evidence hash, preparer identity and idempotency. It should be immutable evidence for an as-of date, not a live query that changes after review.

Continuous run states

A run records control count, balanced count, exception count, blocking exception count, absolute variance, source and resolution evidence hashes, request fingerprint, idempotency key and certification evidence.

Continuous exception states

Verified actions are assigned, investigating, resolved, accepted and reopened. Allowed transitions are status-dependent. For example, an accepted exception cannot be edited into another state silently; it must be reopened.

Prerequisites

Requirement	Why it matters
Stable source and batch/run identity	prevents investigation moving between populations
Correct school and control account	exceptions must not cross scope
Retained bank/provider/import evidence	supports root-cause analysis
Available Payment and journal lineage	distinguishes operational from accounting differences
Control tolerance and materiality	determines warning/blocking treatment
Owner, reviewer and escalation user	prevents ownerless ageing
Due-hour policy	makes escalation measurable
Exact permissions	action, review and policy changes are separate
Append-only correction design	accepted evidence must not be overwritten
Support request IDs/log access	needed for service and integration failures

Roles and exact permissions

Action	Exact ability	Control
List standard items	reconciliation_item:list	use school and batch filters
Read one item	reconciliation_item:read	inspect full linked evidence
Update item metadata	reconciliation_item:update	do not rewrite historical rationale
Find candidates	reconciliation:find_matches	candidate is not resolution
Manual match	reconciliation:manual_match	prove the selected Payment
Resolve discrepancy	reconciliation:resolve_discrepancy	substantive notes required
List continuous runs/controls/exceptions	reconciliation_batch:list	current workspace reuses batch list
Read continuous detail	reconciliation_batch:read	inspect balances/actions/escalations
Create control/run	reconciliation_batch:create	scope and idempotency required
Update/transition evidence	reconciliation_batch:update	status-dependent actions
Review/certify	reconciliation_batch:review	independent attestation
Publish/create supporting item/snapshot	reconciliation_item:create	source evidence must be reproducible
Manage control policy	finance_control:manage_policy	tolerance, owner and due policy
View posting readiness	finance_control:readiness	coordinate P5/P6 gates
Resolve posting exception	finance_posting_exception:resolve	separate accounting exception control

The current Continuous Reconciliation UI uses the exact permissions above. Standard Reconciliation also has dedicated backend operations such as reconciliation_batch:close, reconciliation:auto_match and reconciliation:statistics.

Root-cause classification

Classify before correcting:

Root cause	Examples	Primary owner
Missing external evidence	statement/report not received, missing row	treasury/provider operations
Missing internal source	provider success without Payment, unrecorded bank charge	payment operations/accountant
Duplicate internal source	duplicate Payment or journal	Finance control owner
Incorrect link	wrong student, Payment or bank transaction	reconciliation analyst
Timing	payout or value date not yet reached	treasury
Amount	fee, split, partial, rounding or chargeback	accountant/provider analyst
Currency/FX	wrong currency, missing rate, provider conversion	accountant/treasury
Classification	wrong GL account or posting mapping	accounting control owner
Snapshot failure	source snapshot missing/stale	system owner/data steward
Source defect	bank/provider file inconsistent	external institution/support

Do not resolve a missing source by creating an arbitrary manual journal, and do not resolve a posting classification error by changing the bank match.

Investigation workflow

1. Freeze the exception context

Record item/exception ID, batch/run ID, school, source, amount, currency, dates, current status, owner, severity and due time.

2. Read the lineage

Trace:

• bank/provider/cash source;
• import and original row;
• reconciliation item;
• Payment Attempt and Payment;
• allocation/receipt where relevant;
• journal document and lines;
• control account and snapshot;
• previous actions and escalations.

3. Reproduce the difference

For a standard item, reproduce the amount/reference mismatch. For Continuous Reconciliation, compare subledger snapshot balance, GL balance, variance, tolerance, materiality and result.

4. Classify root cause

Choose the responsible workflow rather than the fastest screen.

5. Apply the safe correction

Examples:

• correct a wrong match;
• publish the missing snapshot;
• complete an idempotent Payment recovery;
• post a governed bank charge;
• reverse/replace an incorrect journal;
• retain a timing difference;
• obtain a provider report;
• mark a true non-payment line ignored with authority.

6. Record evidence

Use substantive notes and include identifiers, request IDs, source checksum, before/after values and the approved correction record.

7. Resolve

Move the standard discrepancy to its supported resolution outcome or transition the continuous exception to resolved.

8. Independent acceptance

A reviewer verifies the correction and moves a continuous exception to accepted. The reviewer must check that the next run or recalculation no longer produces the unsupported difference.

Escalation model

Continuous controls can store warning and blocking due hours plus an escalation user. Escalation records retain level, reason, target, actor, note, evidence hash and time. Escalation is not resolution; it changes visibility and responsibility.

Certification readiness

A run should not be certified merely because the dashboard looks mostly green. Verify:

• every enrolled control has required snapshot evidence;
• control account identity and normal balance are correct;
• blocking exceptions are cleared or policy explicitly prevents certification;
• resolved exceptions are accepted where required;
• source and resolution evidence hashes are stable;
• a superseding run has not invalidated the evidence;
• the certifier is independent and records a substantive attestation.

Accounting and workflow handoffs

Exception	Correct handoff
Missing Payment for provider success	P4 attempt/Payment recovery
Wrong Payment allocation	P4 reallocation/correction
Missing journal	P5 posting diagnostics/remediation
Wrong journal classification	P5 reversal and corrected posting
Bank fee/interest	governed bank-originated accounting
Provider payout timing	P6 open settlement item
Missing statement row	bank/provider source escalation
Student account disagreement	P3/P4 source investigation
Snapshot pipeline failure	system/data owner
Material unresolved control variance	controller and period-close blocker

Worked scenario: Mupfure Learning Academy

Mupfure’s daily Accounts Receivable control compares a subledger snapshot of USD 84,250 with a GL control balance of USD 84,475. The variance is USD 225, above the warning tolerance and classified blocking under the school’s materiality policy.

The generated exception points to an AR control account and retains both evidence hashes. The accountant is assigned as owner and begins investigation. They find one verified Payment of USD 225 whose Payment record exists but whose journal is missing after an earlier service interruption.

The accountant runs the approved P5 dry-run remediation. It plans one posting. After independent approval, the journal is applied under a stable idempotency key. The owner reruns the relevant control evidence; the GL and subledger now agree. The exception is moved to resolved with the Payment ID, journal ID, dry-run result and request ID. The reviewer confirms the new evidence and accepts it. The daily run becomes ready for certification and a different user records the attestation.

Failure modes

Symptom	Likely cause	Evidence to inspect	Safe action	Escalate when
Exception repeatedly returns	symptom was hidden, root cause not corrected	prior actions and next run evidence	reopen and classify root cause	accepted corrections are ineffective
Owner cannot be assigned	missing user/access or invalid scope	control owner IDs and permissions	correct governance configuration	no accountable user exists
Resolved cannot become accepted	wrong status or reviewer permission	action history and reconciliation_batch:review	follow state sequence	backend transition conflicts with contract
Snapshot is missing	source job failed or control not enrolled	source system, watermark, schedule	restore/publish evidence idempotently	source population cannot be reproduced
Variance changes during review	mutable source population or new postings	snapshot hash, GL as-of cutoff	prepare a superseding run	evidence cannot be frozen
Blocking exception is ignored	misuse of standard ignored action or policy gap	severity/materiality and action log	reopen and require controller review	certification/close already occurred
Wrong journal used to force balance	accounting workaround instead of source correction	journal source and rationale	reverse and apply correct workflow	statements were issued
Escalation exists but no work occurs	escalation mistaken for resolution	owner, due time and actions	assign action owner and deadline	critical SLA breach
Duplicate recovery creates two Payments	uncertain callback handled manually	attempt/provider IDs and audit	quarantine duplicates	both affected allocations/journals

Verification checklist

• Exception identity, school, source, amount and currency are fixed.
• Current status, severity, owner, reviewer and due date are visible.
• Original source, import, Payment and journal lineage is retained.
• Root cause is classified before correction.
• Correction uses the owning workflow.
• Before/after values and identifiers are recorded.
• Evidence hashes and snapshots remain immutable.
• Resolution notes are substantive.
• Independent acceptance is recorded when required.
• Escalation records do not substitute for resolution.
• The next comparison confirms the difference is removed or properly retained.
• Certification is blocked when required.
• Period-close evidence references unresolved material exceptions.

Practice and knowledge check

Guided practice: create a test control with one balanced result, one missing snapshot and one material variance. Assign owners, resolve each through the correct workflow and certify only after review.

Independent scenario: an analyst marks a USD 1,000 bank credit ignored because no Payment exists. Explain the control failure and design the correct investigation.

1. What is the difference between ignored and accepted?
2. What creates a missing-snapshot exception?
3. Why must snapshots be immutable?
4. Which states occur before continuous certification?
5. What does blocking severity mean?
6. Why is escalation not resolution?
7. Which permission manages control policy?
8. When should an exception be reopened?
9. Why should a journal not be used to force a reconciliation balance?

Answer guide: ignored classifies an item while accepted approves a resolution; absent required source evidence creates the exception; immutable evidence makes comparisons reproducible; preparing/open/ready precede certified; blocking prevents the governed gate; escalation changes ownership/urgency; use finance_control:manage_policy; reopen when later evidence invalidates acceptance; forced journals hide the root cause and distort accounting.

Next lesson

Continue to Bank webhooks and operational monitoring.