Match and reconcile

A reconciliation batch groups external or independently prepared evidence for one controlled comparison. A reconciliation item represents one amount within that batch and may link to a Payment, Invoice and Bank Statement Transaction. Matching records a relationship between external and Makronexus evidence; reconciliation adds review, discrepancy resolution and closure controls.

The verified batch types are bank_statement, payment_gateway, manual and cash_collection. Batch statuses are draft, processing, review, completed, closed and cancelled. Item statuses are pending, matched, unmatched, discrepancy, resolved and ignored.

Audience: reconciliation analysts, accountants, bursars, treasury officers, controllers, auditors and support analysts
Learning time: 60 minutes
Navigation: Finance → Reconciliation (finance/reconciliation)
Control objective: connect each external amount to the correct internal evidence, explain every residual difference and close only after independent review.

Learning outcomes

You will be able to:

• distinguish a batch from an item and a match from reconciliation;
• create a batch with the correct source, date, currency and import lineage;
• interpret batch and item statuses without mixing their meanings;
• run automated matching with controlled thresholds;
• evaluate match candidates using amount, currency, date, reference and party evidence;
• perform manual and bulk matches with exact permissions;
• resolve discrepancies without hiding unexplained value;
• review and close a batch in the verified sequence;
• prove that all items and amounts are accounted for.

Exact definition and boundaries

Concept	Exact meaning	Boundary
Reconciliation batch	controlled container for one source comparison	not the statement file or journal
Reconciliation item	one amount/evidence unit within a batch	not automatically a Payment
Candidate	a possible Payment link and match score	not an approved match
Match	recorded link between item and Payment	not automatically external settlement
Discrepancy	item requiring explanation or correction	not permission to force a match
Resolution	approved outcome with notes and actor evidence	may still require accounting correction
Review	reviewer transition from processing to review	not closure
Close	locks a reviewed batch against further changes	not period close
Statistics	derived counts/rates/amounts	not source-of-truth detail

A batch can be operationally closed while related journals, bank-originated entries or period-close tasks remain separate. Conversely, a period can be close-ready only when required reconciliation evidence is complete under policy.

Batch lifecycle

Verified business rules include:

• batch updates are blocked after closed;
• auto-match is rejected for a closed batch;
• review is allowed when the batch is processing;
• close follows a successful review and expects review status;
• parent batch closure blocks item creation and modification.

The model includes completed, but the current guide’s controlled review path is processing → review → closed. Treat any alternate transition shown by the backend as configuration/service behaviour requiring evidence rather than inventing a universal operator action.

Item lifecycle

The dedicated resolve request uses one of matched, ignored or pending_review as the resolution action and requires resolution notes. The older item status model stores resolved; documentation must show both the action decision and resulting persisted status/evidence rather than assuming labels are interchangeable.

Batch and item model

Prerequisites

Requirement	Why it matters
Correct school	every batch and item is school-scoped
Approved source package	source system, date and reference must be stable
Completed or controlled import where applicable	external rows must be traceable
Currency confirmed	batch and item currency must align
Payment population available	candidates are derived from Makronexus Payments
Required bank/provider/cash evidence	matching cannot rely on narrative alone
Exact permissions	match, review and close use separate abilities
Maker/reviewer separation	creator or matcher should not be sole closer
Duplicate-search procedure	prevents matching the same external value twice
Escalation and write-off policy	unmatched value must not disappear through convenience

Roles and exact permissions

Action	Exact ability	Typical role	Control
List batches	reconciliation_batch:list	analyst, accountant, auditor	read scope must match school
Read a batch	reconciliation_batch:read	analyst or reviewer	inspect details and statistics
Create a batch	reconciliation_batch:create	preparer	identify source/import
Update batch metadata	reconciliation_batch:update	preparer	blocked after close
Review a batch	reconciliation_batch:review	independent reviewer	requires processing state
Close a batch	reconciliation_batch:close	controller	only after review
List items	reconciliation_item:list	analyst	use batch scope
Read one item	reconciliation_item:read	analyst, auditor	inspect all linked evidence
Create an item	reconciliation_item:create	importer/system operator	parent must be open
Update item metadata	reconciliation_item:update	authorised analyst	do not overwrite evidence
Auto-match	reconciliation:auto_match	reconciliation operator	thresholds require approval
Manual match	reconciliation:manual_match	analyst	inspect candidate evidence
Bulk match	reconciliation:bulk_match	senior analyst	maximum 100 pairs per request
Find candidates	reconciliation:find_matches	analyst	suggestions are not decisions
Resolve discrepancy	reconciliation:resolve_discrepancy	reviewer/controller	notes required
View statistics	reconciliation:statistics	manager or auditor	verify against item detail

The current general Reconciliation page also accepts legacy/generic Finance payment gates in some frontend paths. Backend route permissions above are the authoritative operation-level contract. A visible button is not a substitute for the exact permission.

Matching strategies and thresholds

The verified strategy labels include auto_exact, auto_fuzzy, exact, fuzzy, intelligent, manual and suggested. The service guide states that auto-match currently uses fuzzy matching while applying the supplied configuration.

Setting	Meaning	Default in current guide	Control concern
Exact amount matching	require or reward exact amount	true	split/net settlements may differ
Fuzzy amount tolerance	accepted amount variance	1	unit/percentage semantics must be confirmed in UI
Date tolerance days	candidate date window	3	value date and payment date can differ
Reference matching	include reference evidence	true	references may be truncated/reused
Minimum match score	threshold for automatic match	80	score is not proof by itself

Candidate lookup is documented as returning completed, unreconciled Payments within approximately ±5% of the item amount, with match scores and differences. Treat those conditions as candidate filtering—not an authorisation rule.

Matching decision model

Guided procedure

1. Create the batch

Choose New batch with reconciliation_batch:create.

Enter:

• batch type;
• source system;
• statement date;
• statement/batch reference;
• currency;
• notes;
• Bank Statement Import ID where applicable;
• expected record count and total amount where available.

Expected result: a draft batch exists for the selected school.
Control: one source package should not be split or duplicated without a documented reason.

2. Verify batch population

Open the batch and compare total records, total amount, item count and source/import lineage.

Expected result: every external source row intended for reconciliation is represented once.
Control: do not begin matching if the batch population is incomplete.

3. Configure auto-match

Use the approved threshold profile. Record the values used and why they are appropriate for this source.

Expected result: the operator can reproduce the matching run.
Control: do not widen tolerances merely to improve the match-rate percentage.

4. Run auto-match

Use reconciliation:auto_match.

Expected result: the batch enters processing and returns processed, matched, unmatched and discrepancy counts, plus any item errors.
Control: compare the returned counts to the batch population.

5. Review every automatic match

Sample or review according to policy, prioritising:

• high amounts;
• fuzzy matches;
• missing/truncated references;
• date differences;
• payer/student ambiguity;
• cross-campus risks;
• net/gross provider differences;
• previously reversed or refunded Payments.

Expected result: automatic links are supported by evidence, not just score.

6. Work unmatched items

Load candidates with reconciliation:find_matches. For each candidate compare Payment number, status, date, amount, currency, student, method, reference, difference and tags.

Expected result: a manual match is created only when one Payment is proven.

7. Use bulk match carefully

Bulk match accepts up to 100 item/Payment pairs. Prepare a reviewed worksheet or controlled selection set before submitting.

Expected result: matched count plus returned errors equals the submitted population.
Control: never use bulk match to bypass individual investigation.

8. Resolve discrepancies

A discrepancy may arise from amount, currency, timing, duplicate evidence, missing internal record, bank fee, reversal, chargeback, wrong student/payment, or a source error.

Use reconciliation:resolve_discrepancy with substantive notes and one of the supported resolution actions.

Expected result: the item retains the decision, actor, time and any linked Payment.
Control: ignored means an authorised non-match classification; it does not mean the value is unimportant.

9. Review the batch

An independent user with reconciliation_batch:review verifies:

• all items accounted for;
• unmatched/discrepancy/ignored items explained;
• counts and amounts reconciled;
• source evidence retained;
• accounting corrections completed or cross-referenced;
• no duplicate external or Payment use;
• match configuration recorded.

Expected result: processing batch moves to review.

10. Close the batch

A controller with reconciliation_batch:close records close notes.

Expected result: batch becomes closed, closedAt is populated and further item changes are blocked.
Control: closing the reconciliation batch does not close the accounting period.

Reconciliation arithmetic

At minimum, prove these conservation relationships for the chosen scope:

total items = matched + unmatched + discrepancy + resolved + ignored + pending

Status overlap/aggregation rules must follow the backend statistics response; do not double-count a resolved item in both current-state totals.

For amount control:

batch total amount = explained matched amount + explained residual amount

Residual amount includes authorised timing differences, unresolved exceptions and approved ignored/non-payment activity. “Explained” must be supported by evidence.

Accounting and settlement handoffs

Outcome	Required next control
Correct Payment matched, journal exists	verify bank and GL linkage
Payment matched, journal missing	P5 posting diagnostics/remediation
Bank fee with no internal source	governed bank-originated accounting
Unknown receipt	hold as reconciliation exception
Provider net settlement	reconcile gross collections, fees and payout evidence
Reversal or chargeback	trace original Payment and append correction
Cash deposit	link custody/deposit batch and bank credit
Timing difference	retain open item until clearing evidence exists

Worked scenario: Mupfure Learning Academy

Mupfure creates a bank_statement batch for 146 USD statement transactions. Auto-match processes all items: 126 match, 12 remain unmatched, five become discrepancies and three return item-level errors.

The analyst reviews all fuzzy matches above USD 500. One candidate has the same amount and date but belongs to another campus, so it is unlinked and marked discrepancy. Eight unmatched items are parent deposits with truncated references; supporting deposit slips prove seven Payments. The eighth is an unknown credit and remains open.

Two discrepancies are bank charges. They are not matched to Payments; governed bank-originated accounting requests are created and cross-referenced. One discrepancy is a duplicated source row, classified ignored with checksum and row evidence. The final discrepancy is a chargeback requiring a separate correction.

The reviewer confirms that every item and amount is explained. The batch moves to review and is then closed by a controller. The unknown credit remains in an exception control with an owner and due date; the close note identifies it as an approved outstanding item under policy rather than pretending it was matched.

Failure modes

Symptom	Likely cause	Evidence to inspect	Safe action	Escalate when
Match rate is unexpectedly high	tolerance too broad or duplicate Payments	match config, candidate scores, reused payment IDs	pause and sample high-risk matches	wrong links affected accounting/receipts
Match rate is unexpectedly low	missing Payments, date/reference differences or wrong currency	source rows and candidate filters	classify causes before changing thresholds	expected Payments cannot be found
Batch cannot be reviewed	wrong status or unresolved service errors	batch status and auto-match response	complete processing and resolve errors	status contradicts evidence
Batch cannot close	not in review or missing permission	status and reconciliation_batch:close	use controlled review path	reviewed batch still rejected
Manual match points to wrong Payment	ambiguous candidate selected	amount, student, payer, reference, date	unlink/correct under authority	downstream journal/receipt must be reversed
Bulk match partly fails	invalid item/payment pair or closed batch	per-item errors	reconcile successful and failed results	response counts do not conserve
Discrepancy resolution rejected	item not in discrepancy or notes/action invalid	current item status and request	correct workflow state	backend state is inconsistent
Closed batch needs correction	evidence discovered after close	close notes, item history, source	use governed reopen/correction process if supported	no append-only correction path exists
Same Payment matched twice	duplicate source or missing uniqueness control	Payment ID across items/batches	quarantine and determine authoritative match	financial statements already relied on it

Verification checklist

• Batch scope, type, source, date, reference and currency are correct.
• Import/source evidence is linked.
• Item count and total amount reconcile to source.
• Auto-match configuration is recorded and approved.
• Returned processing counts equal the population.
• High-risk and fuzzy matches are reviewed.
• Manual matches include supporting evidence.
• Bulk matches reconcile successes and errors.
• Every unmatched/discrepancy/ignored item has an owner or reason.
• Payment IDs are not reused incorrectly.
• Accounting differences are cross-referenced to P5 controls.
• Independent review is recorded.
• Close follows review and locks further changes.
• Batch close is not confused with period close.

Practice and knowledge check

Guided practice: create a ten-item test batch with six exact matches, one fuzzy candidate, one bank fee, one unknown credit and one duplicate row. Process every item and produce a close checklist.

Independent scenario: auto-match links a USD 200 bank credit to a Payment for another student with the same amount and date. Explain why the score cannot authorise the match and identify the evidence needed.

1. What is the difference between a batch and an item?
2. What does a candidate prove?
3. Which ability runs auto-match?
4. Why should tolerances not be widened to improve a KPI?
5. What is required before batch review?
6. What state is required before close?
7. What does ignored mean?
8. Why is batch close not period close?
9. What must be done when a matched Payment has no journal?

Answer guide: a batch is the comparison container and items are amounts; candidates are suggestions; auto-match uses reconciliation:auto_match; thresholds affect risk; population, matches, exceptions, totals and evidence must be complete; close follows review; ignored is an authorised classification with evidence; the records govern different scopes; missing journals follow P5 diagnostics/remediation.

Next lesson

Continue to Settlement and provider reconciliation.