Currencies and exchange-rate governance
Currency configuration determines which monetary units a school uses and where each amount belongs. Exchange-rate governance determines how a rate is sourced, dated, approved, and evidenced when one currency must be related to another.
Audience: bursars, accountants, implementers, approvers, auditors, and localisation owners
Learning time: 35 minutes
Availability: multiple currencies are represented across Finance records; exact rate sourcing and localisation policy remain configuration-dependent
Boundary: a three-letter currency field does not prove that a provider, bank, report, or statutory pack supports that currency.
Learning outcomes
You will be able to:
- distinguish primary, transaction, account, bank, and presentation currency;
- identify where Makronexus stores currency context;
- configure supported currencies without mixing unrelated amounts;
- describe the minimum evidence required for a manual exchange rate;
- recognise when rates and reports require separate certification;
- test currency configuration with representative records;
- avoid universal claims about Zimbabwean or other country-specific exchange rules.
Currency contexts
| Context | Meaning | Example |
|---|---|---|
| Primary currency | school’s configured operational reference in the process profile | USD |
| Supported currencies | currencies the school intends to use | USD and configured local currency |
| Fee currency | currency in which a fee is defined | USD tuition |
| Invoice currency | currency of the student obligation | USD |
| Payment currency | currency received | USD or another supported currency |
| Bank-account currency | currency of the external account | USD |
| GL/journal currency | currency carried by the accounting entry | USD |
| Statement filter/presentation | currency requested for a report | USD |
| Provider currency | currency supported by the connected provider | external/configuration-dependent |
Never add unlike currencies. USD 100 + ZAR 100 is not a meaningful total until a controlled conversion rule is applied.
Verified product boundaries
Current contracts show currency on:
- financial process profiles;
- accounting books;
- fiscal years;
- fees and payment plans;
- invoices and credit notes;
- payments and allocations;
- receipts and receipt settings;
- bank accounts and reconciliation tolerances;
- scholarship programs, awards, and applications;
- discount programs and applications;
- GL accounts, journals, and statements;
- approval matrices and posting mappings.
The product also has enterprise FX control surfaces and manual-payment-rate approval evidence. P2 does not claim one universal exchange-rate master screen or one automatic translation method for every workflow.
Rate evidence model
Every exchange-rate decision should record:
| Evidence | Question answered |
|---|---|
| Base currency | one unit of what currency? |
| Quote currency | expressed in what currency? |
| Rate value | what multiplier/divisor is used? |
| Quote direction | does 1 base = rate quote or the inverse apply? |
| Effective timestamp/date | when is the rate valid? |
| Source | central bank, commercial bank, provider, treasury policy, or manual quote |
| Source reference | document, API response, or approved schedule |
| Purpose | payment conversion, statement presentation, settlement, revaluation, or other |
| Approver | who authorised use? |
| School/tenant scope | where may it be used? |
| Rounding policy | decimal precision and tie-breaking |
| Reversal/correction link | how is an incorrect rate corrected without erasing evidence? |
Prerequisites
| Requirement | Why it matters |
|---|---|
| Approved school currency design | prevents users choosing currencies ad hoc |
| Named rate source owner | external policy must have an accountable owner |
| Supported provider/bank confirmation | product field support does not equal external availability |
| Chart of Accounts currency design | bank and control accounts need coherent context |
| Fiscal-year currency | calendar evidence must align with implementation design |
| Rounding policy | small differences affect allocations and reconciliation |
| Approval rule | manual rates can alter value and require control |
| Localisation review | statutory presentation and reporting rules vary by country |
Roles and exact permissions
Currency touches several resources, so there is no single universal “currency admin” permission.
| Action | Exact ability or owner |
|---|---|
| Update process profile currencies | financial_process_setup:update |
| Create/update bank accounts and provider settings | school_bank_setting:create, school_bank_setting:update |
| Create/update fees | financial_fee:create, financial_fee:update |
| Configure posting policy/mappings | finance_control:manage_policy, finance_control:create, finance_control:update or governed change-request abilities |
| Manage enterprise FX control/certification | financial_fx:manage |
| Create/approve manual payment rate evidence | workflow-specific FX abilities where exposed; verify against the active screen/API |
| View statements | gl:statements on the GL contract |
| Approve threshold routes by currency | financial_approval_matrix:list, financial_approval_matrix:create, financial_approval_matrix:update, financial_approval_matrix:activate, financial_approval_matrix:simulate |
Do not grant broad payment mutation rights simply to maintain rate evidence.
Guided configuration procedure
1. Record the currency design
For the test school, document:
- primary currency;
- supported transaction currencies;
- bank-account currencies;
- fee currencies;
- provider currencies;
- GL account currency restrictions, if any;
- report/presentation currencies;
- rate sources and purposes;
- rounding and tolerance rules.
2. Configure the process profile
Open Finance → Finance Controls → Finance Setup → Process Configuration (finance/setup/workflows). Set the approved primary and supported currencies on the school-owned profile.
Expected result: school process configuration records the intended currency mode.
Control: do not rely on a tenant default without confirming it applies to the school.
3. Configure currency-bearing foundations
Review:
- fiscal-year currency;
- accounting-book currency where applicable;
- bank-account currency;
- fee and discount-program currency;
- scholarship program/award currency;
- posting policy default currency;
- account mappings restricted by currency where required.
4. Configure rate governance
Where a workflow exposes a rate or rate-evidence control, require source, date, direction, purpose, and approval according to school policy. For provider-generated rates, retain provider evidence and settlement values.
Do not document “Makronexus automatically converts all payments” unless the specific workflow contract and provider configuration prove it. Payments can carry exchange-rate metadata, but automation and rate source vary.
5. Test representative cases
Use test data for:
- fee, invoice, and payment in the same currency;
- bank account and payment in the same currency;
- payment or allocation requiring a rate, where supported;
- approval matrix with currency-specific threshold;
- posting simulation with currency-specific mapping;
- statement query with an explicit currency;
- rounding/tolerance edge case.
6. Verify evidence
For each converted result, independently recompute:
converted amount = source amount × approved rate
or the inverse, according to the recorded quote direction. Verify rounding after conversion, not before, unless the approved policy states otherwise.
Worked scenario: Mupfure Learning Academy
Mupfure Learning Academy configures USD as the primary currency and a locally approved second currency for selected collections. The school has separate bank accounts per currency and does not combine their balances without a documented presentation-rate process.
The implementation team:
- configures both currencies in the school process profile;
- defines each fee in one currency;
- links each bank account to its own currency and GL account;
- creates currency-specific approval thresholds;
- configures currency-specific posting mappings where required;
- records the approved manual-rate source and quote direction for supported cross-currency operations;
- tests a same-currency payment first;
- tests one controlled conversion case;
- verifies the journal and reconciliation evidence;
- documents which reports are native-currency and which require certified presentation rates.
Failure modes
| Symptom | Likely cause | Evidence to inspect | Safe action | Escalate when |
|---|---|---|---|---|
| Currency selector lacks expected code | profile, page enum, provider, or feature does not expose it | process profile, API contract, provider certification | use only supported/configured values | approved currency is supported by contract but unavailable |
| Allocation total differs after conversion | quote direction, rate date, or rounding error | source amount, rate evidence, calculation | recompute and correct through governed action | stored calculation contradicts approved evidence |
| Bank reconciliation has small variance | tolerance/rounding or settlement fee | bank settings, provider settlement, rate/timestamp | investigate evidence; do not force match | variance exceeds approved tolerance |
| Statement totals cannot be compared | different currency filters or presentation rates | report parameters and certification | rerun with explicit comparable scope | same scope still differs |
| Manual rate cannot be approved | missing ability, stale evidence, self-approval restriction | permissions, approval request, actor identities | use independent approver | no eligible reviewer exists |
| Fee and bank currencies conflict | incorrect design or wrong account | fee, invoice, bank account, mapping | correct configuration before transactions | existing posted activity requires correction |
Verification checklist
- Primary and supported currencies are approved and recorded.
- Every fee, bank account, book, and fiscal year has intentional currency context.
- Provider currency support is confirmed externally.
- Rate source, direction, date, purpose, and approver are retained.
- Rounding and reconciliation tolerance are documented.
- Currency-specific approval routes simulate correctly.
- Currency-specific posting mappings simulate correctly.
- Same-currency and supported conversion tests pass.
- Statements are compared only with explicit currency and date scope.
- Localisation owner has reviewed statutory presentation requirements.
Practice and knowledge check
Guided practice: build a currency matrix for Mupfure Learning Academy showing every configuration object and its currency.
Independent scenario: a guardian pays in a currency different from the invoice. List the evidence required before recording any conversion.
- Why can two amounts with the same number not be added if currencies differ?
- What is quote direction?
- Why is a currency field not proof of provider support?
- Which data must accompany a manual rate?
- Why can statement presentation require separate certification?
- Where can currency-specific approval routing be configured?
- What should happen when an incorrect historical rate is discovered?
Answer guide: currencies represent different units; quote direction defines the equation; external availability varies; source/date/direction/purpose/approval are required; presentation changes value representation; approval matrices route by currency; use governed correction/reversal evidence rather than erasure.
Next lesson
Continue to Chart of Accounts and posting mappings.