Bank statement lifecycle

A bank statement import is a school-scoped record that identifies one external statement source and carries statement-level evidence such as the source system, statement reference, statement date, currency, opening balance, closing balance and retained file reference. A bank statement transaction is one external line attached to that import. It records the transaction date, optional value date, amount, currency, bank-specific type, reference, narrative and reconciliation status.

Audience: bursars, accountants, treasury officers, reconciliation analysts, auditors, implementers and support analysts
Learning time: 45 minutes
Navigation: Finance → Bank statements (finance/bank-statements)
Phase boundary: this chapter explains external bank evidence and its lifecycle. It does not claim that importing or completing a statement automatically creates a Payment, journal, reconciliation batch or provider settlement.

Learning outcomes

You will be able to:

• distinguish a statement import from its transactions;
• explain statement date, transaction date and value date;
• interpret every verified import and transaction status;
• identify exact permissions for listing, reading, creating and updating bank evidence;
• explain why import completion is not reconciliation;
• preserve statement provenance and control totals;
• identify when a line should be matched, reconciled, ignored or placed in error;
• verify the handoff to matching, bank-originated accounting and period-close evidence.

Exact definition and boundaries

The Bank Statements module ingests external bank data to seed reconciliation workflows. The import header and its transaction lines are evidence about what the external institution reported. They are not replacements for Makronexus operational or accounting records.

Record or event	What it proves	What it does not prove
Statement file	the school received a source document	that every row was parsed correctly
Bank statement import	Makronexus registered the statement identity and control information	that all rows were committed
Bank statement transaction	one external movement was stored	that the movement belongs to a particular Payment
matched transaction	a payment link or matching decision was recorded	that accounting and external settlement are complete
reconciled transaction	the line passed the configured reconciliation decision	that the period is closed
Completed import	the import workflow completed	that all transaction lines are matched
Archived import	the import is retained outside normal active work	that evidence may be deleted

The verified transaction model stores amounts as supplied. A credit/debit helper exists for presentation, but bank-specific transaction types may be preserved. Do not infer economic direction from the sign or label without checking the approved mapping for the source institution.

Record relationships

The relationship to a Payment is optional. An imported line can remain unmatched, become a discrepancy, be ignored under policy, or require another source record.

Dates and balances

Field	Exact meaning	Control question
Statement date	date associated with the statement header	Is it the issued date, period end or file date for this bank?
Transaction date	bank booking date for one line	Which reporting and matching window uses it?
Value date	optional clearing/effective date	Does settlement timing differ from booking?
Opening balance	optional statement control total	Does it agree with the preceding statement?
Closing balance	optional statement control total	Can it be reproduced from opening balance and movements?
Currency	statement/import currency	Is the file single-currency, and is case/format approved?
Statement reference	stable external identity	Is it unique for the school and source?
Source system	bank, adapter or manual source identity	Which mapping profile and operating owner apply?

A statement can be internally arithmetically consistent while containing duplicate, omitted or misclassified rows. Control totals are one test, not the whole reconciliation.

Import status model

Status	Meaning	Allowed operating response
pending	registered and awaiting processing	confirm source identity and avoid duplicate submission
processing	ingestion or downstream work is active	monitor; do not create a second import for the same statement
completed	the import workflow finished	reconcile row counts, totals and exceptions
failed	processing did not complete	inspect diagnostics and retry only with duplicate controls
archived	retained outside the active queue	preserve evidence; do not append transactions

The backend prevents transactions being appended to an archived import.

Transaction status model

The available status API can update status, notes and an optional matchedPaymentId. Status changes are audited. The product contract allows unlinking by setting the payment link to null, but the operating reason and reviewer evidence must be retained.

Prerequisites

Requirement	Why it matters
Correct tenant and school	imports and lines are school-scoped and protected by row-level security
Approved bank account and source system	prevents statements being attached to an ambiguous institution
Stable statement reference convention	supports duplicate detection and audit retrieval
Confirmed currency	prevents matching across an unintended currency
Retained source file or secure file reference	permits re-performance and audit review
Import mapping profile or approved manual layout	makes row interpretation repeatable
Opening and closing balance evidence	supports control-total verification
Separation of importer and reconciler	reduces self-review risk
Exact permissions	frontend visibility is not proof that the backend will allow a mutation

Roles and exact permissions

Action	Typical owner	Exact ability	Separation rule
List imports	accountant or treasury analyst	bank_statement_import:list	read-only access may be broad
Read one import	accountant, auditor or support analyst	bank_statement_import:read	sensitive file links remain controlled
Create an import	treasury preparer	bank_statement_import:create	reviewer should confirm counts and totals
Update import status	reconciliation lead	bank_statement_import:update	status completion must not be self-certified without review
List transactions	reconciliation analyst	bank_statement_transaction:list	needed for matching and bank-originated controls
Read one transaction	analyst or auditor	bank_statement_transaction:read	preserve privacy and bank narrative controls
Append transactions	import preparer	bank_statement_transaction:create	do not append after archival
Update transaction status/link	reconciliation reviewer	bank_statement_transaction:update	record notes and evidence for unlink/ignore/error decisions
Read governed bank accounting	accountant	finance_control:read	separate from raw import access
Request bank-originated accounting	authorised maker	finance_control:request_change	requires transaction visibility
Approve bank-originated accounting	independent approver	finance_control:approve	maker must not approve own request
Review readiness	controller or auditor	finance_control:readiness	readiness is evidence, not permission to post

End-to-end lifecycle

Guided procedure

1. Establish source identity

Before opening Makronexus, record the bank account, statement period, statement reference, currency, source channel, file name, receipt timestamp and checksum. Confirm that no import already exists for the same school, source and reference.

Expected result: one controlled source package exists.
Control: do not rename a duplicate file and treat it as a new statement.

2. Open Bank statements

Navigate to Finance → Bank statements and confirm the selected school.

Expected result: imports for that school appear.
System effect: no financial records change during viewing.

3. Review existing imports

Search by statement reference and source system. Inspect pending, processing, failed and completed records.

Expected result: the operator can prove whether the statement is new, retried or already processed.

4. Create or import the statement

Use the import wizard if you have bank_statement_import:create. Enter the exact source system, statement reference, statement date, opening balance, closing balance, currency and retained file reference.

Expected result: an import is created or prepared for preview.
Control: currency and statement reference must be copied from approved evidence, not guessed.

5. Verify transactions

Compare source row count, accepted row count, warning/error count, debit/credit or signed totals and closing balance movement. Inspect transaction date, value date, amount, reference and narrative.

Expected result: every committed line is traceable to an original row.

6. Manage import status

Only update the import to completed when ingestion is complete and control totals are explained. Use failed when the import did not complete; use archived only after the evidence is no longer active.

Expected result: status describes import processing, not reconciliation quality.

7. Handoff to reconciliation

Create or identify the related reconciliation batch and retain the import ID. Ensure imported lines remain visible for candidate matching and discrepancy investigation.

Expected result: external evidence and operational matching work are linked without collapsing their statuses.

Accounting impact

Importing a statement does not, by itself, prove a journal should be posted. Bank-originated accounting is governed separately because some bank movements may represent fees, interest, direct deposits, reversals, transfers or activity already represented by another source record.

Bank event	Possible accounting response	Publication rule
Customer deposit already represented by a Payment	match/reconcile existing Payment and journal	do not post a duplicate
Bank charge	governed bank-originated accounting request	account mapping and approval required
Interest received	governed accounting request	policy and account mapping required
Transfer between school accounts	link both sides and avoid revenue classification	bank/account identity required
Unknown credit	hold as exception	do not invent student or income ownership
Reversed bank movement	trace original event and correction	append-only correction evidence

Worked scenario: Mupfure Learning Academy

Mupfure receives its USD current-account statement for 31 July. The file reports an opening balance of USD 18,420, 146 transaction rows and a closing balance of USD 23,870. The treasury preparer records the source as mupfure-bank-online, uses the bank’s statement reference, and confirms the checksum.

The preview identifies 141 accepted rows, three warning rows with truncated references, one error row with an invalid date and one intentionally ignored header row. The school corrects the date from the source document, reviews the three warnings and commits them only after confirming amount and value date. The committed count and totals are reconciled before the import becomes completed.

The accountant then creates a bank-statement reconciliation batch. A school-fee deposit matches an existing Payment; a bank charge becomes a governed accounting request; one unknown credit remains an exception. The import is not archived until the batch is closed and evidence retention requirements are met.

Failure modes

Symptom	Likely cause	Evidence to inspect	Safe action	Escalate when
Duplicate statement appears	repeated upload or changed reference	source checksum, school, reference, created time	stop processing and identify authoritative import	both records created economic effects
Row count differs	header/footer handling, parser error or omitted rows	preview summary and source file	reconcile every excluded row	committed lines cannot be tied to source
Closing balance does not reproduce	missing row, direction/sign interpretation or source scope	opening/closing balances and transaction totals	classify the difference before completion	bank evidence itself is inconsistent
Import remains processing	background failure or incomplete job	request ID, import status, logs	do not re-upload blindly	no progress or diagnostic evidence
Transactions cannot be appended	import archived or permission missing	import status and exact ability	reopen through approved policy or create correct active import	archived evidence must be changed
Currency differs across lines	source is multi-currency or mapping fault	row currency and import currency	split or correct according to approved design	product contract cannot represent source
Matched payment is wrong	weak reference or manual selection error	payment ID, amount, date, payer and notes	unlink under authority and rematch	journal or receipt effects need correction
Completed import has unmatched lines	completion confused with reconciliation	line statuses and batch statistics	continue reconciliation; do not downgrade evidence silently	close was already approved

Verification checklist

• Correct tenant and school are selected.
• Source bank account and source system are documented.
• Statement reference is stable and duplicate-checked.
• Source file or secure reference and checksum are retained.
• Statement date, opening balance, closing balance and currency are verified.
• Committed row count is reconciled to source rows.
• Every warning, error and ignored row has a reason.
• Import status reflects ingestion only.
• Transaction statuses reflect matching/reconciliation decisions only.
• Payment links, notes and actor timestamps are reviewable.
• Bank-originated accounting is separately governed.
• Reconciliation batch and import identifiers are cross-referenced.
• Archival follows retention and close policy.

Practice and knowledge check

Guided practice: use a test statement with ten rows, one warning and one invalid row. Record control totals, preview, correct the invalid row, commit and prove the final row count.

Independent scenario: a completed statement import contains two unmatched credits and a matched bank charge. Explain why none of those facts alone proves the bank account is reconciled.

1. What is the difference between an import and a transaction?
2. What does completed prove?
3. Why can transaction date and value date differ?
4. Which ability appends transactions?
5. Why should a statement reference and checksum both be retained?
6. What is the difference between matched and reconciled?
7. Why must a bank charge not automatically become a new journal?
8. When is archived appropriate?

Answer guide: the import is the statement header and transaction records are lines; completion is ingestion status; banks book and clear at different times; append uses bank_statement_transaction:create; the two identifiers support duplicate and provenance controls; matching links evidence while reconciliation completes the approved comparison; accounting may already exist or require mapping/approval; archival follows completed operating and retention criteria.

Next lesson

Continue to Import bank statements.