Accounting model in plain language
Makronexus has an internal General Ledger. Operational Finance modules can post accounting transactions into it, and financial statements read from it. Ledger exports package posted data; they are not the source ledger.
Audience: bursars, accountants, administrators, auditors and implementers
Learning time: 30 minutes
Learning outcomes
You will be able to:
- explain the internal General Ledger;
- identify the five account types and normal balances;
- explain a double-entry journal;
- distinguish operational records from accounting records;
- explain why reversals are append-only;
- identify the date, school and currency context of a statement.
The accounting chain
Posting is configuration-dependent. The diagram does not claim that every operational record automatically creates a journal.
Core pieces
| Piece | Backend object | Purpose |
|---|---|---|
| Chart of Accounts | gl_accounts | account master data |
| Journal Entries | gl_journal_entries | debit and credit accounting evidence |
| GL API | /api/v1/financial/gl | accounts, manual journals, reversals and statements |
| Ledger Exports | /api/v1/financial/ledger-exports | packaging and downstream handoff |
Account types
| Account type | Plain-language purpose | Normal balance |
|---|---|---|
| Asset | resources controlled by the school, such as cash or receivables | debit |
| Liability | obligations owed to others or amounts held for future recognition | credit |
| Equity | accumulated ownership or fund balance | credit |
| Revenue | income earned by the school | credit |
| Expense | costs consumed by the school | debit |
A normal balance describes the side on which the account usually increases. It is not a rule that the account can never show the opposite sign.
Tenant defaults and school overrides
Makronexus supports:
- a tenant-default account with no school ID;
- a school-specific account for a selected school.
School-scoped account-code lookup uses:
Cross-school account parentage is rejected. Tenant-level posting without school context uses tenant-default accounts only.
Posting and header accounts
A posting account can receive journal entries. A header account groups child accounts and cannot be used as a debit or credit side.
Before posting, an account must:
- exist in the tenant/school scope;
- be active;
- not be a header;
- be different from the account on the other side.
Double entry
Every current GL journal entry has one debit account and one credit account for the same positive amount.
The entry is balanced by construction because debit and credit use the same amount.
Illustrative tuition example
The accounts below are examples only. The actual account codes and posting timing come from the school’s configured Chart of Accounts and posting rules.
| Event | Debit | Credit |
|---|---|---|
| Issue tuition invoice | Student receivable | Tuition revenue |
| Receive and post bank payment | Bank/cash | Student receivable |
| Apply approved credit note | Tuition revenue or configured adjustment account | Student receivable |
P5 will document exact posting procedures and verified mappings.
Journal identity and source
A journal entry includes:
- entry date;
- debit account;
- credit account;
- amount;
- description;
- source type and source ID;
- school ID;
- currency;
- optional cost-centre and revenue-stream codes;
- status;
- metadata and actor evidence.
Source type and source ID provide the bridge back to the operational record.
Journal states
The API accepts draft or posted at creation; posted is the default for a manual journal if status is omitted.
Reversal
A reversal:
- creates a new journal with the original debit and credit accounts swapped;
- preserves the amount and traceability;
- marks the original entry as
reversed; - keeps both the original and correcting evidence.
A reversal is not deletion.
Operational versus accounting records
| Operational record | Accounting record | Relationship |
|---|---|---|
| Invoice | journal entry | invoice can be the posting source |
| Payment | journal entry | payment can be the posting source |
| Credit note | journal entry | adjustment can be the posting source |
| Receipt | usually document evidence | receipt is not itself the ledger |
| Bank statement line | reconciliation evidence | line confirms external activity, not GL classification |
| Payment attempt | provider evidence | attempt state is not a journal |
Statements
Trial balance
Shows account debit totals, credit totals, normal balances, calculated balances and an isBalanced indicator as of a date.
Income statement
Shows revenue, expenses and net income for a date range.
Balance sheet
Shows assets, liabilities, equity, retained earnings and balance status as of a date.
Cash flow
Shows operating, investing and financing cash movements for a date range. The current API accepts direct or indirect method.
Date semantics
| Statement | Date basis |
|---|---|
| Trial balance | as_of_date |
| Balance sheet | as_of_date |
| Income statement | date_from and date_to |
| Cash flow | date_from and date_to |
A statement can also accept school scope and currency. Always state those parameters when comparing two reports.
Currency boundaries
A journal carries a currency. Accounts may carry optional currency context. Statements accept a currency filter.
P1 does not claim:
- automatic currency translation for every journal;
- one universal exchange-rate source;
- statutory presentation-currency compliance;
- automatic consolidation across schools and currencies.
Those behaviours require verified configuration and later-phase documentation.
Accounting evidence checklist
For a journal:
- journal ID or number;
- status;
- entry date;
- school and currency;
- debit account and credit account;
- positive amount;
- source type and source ID;
- creator and timestamp;
- reversal link and reason if reversed.
For a statement:
- statement type;
- school scope;
- date or date range;
- currency;
- filters;
- balance/readiness indicator;
- source journal population and exceptions.
Common mistakes
| Mistake | Correct understanding |
|---|---|
| “The export is the ledger” | the internal GL is the ledger; exports package data |
| “An invoice is a journal” | invoice is operational obligation; journal is accounting classification |
| “A receipt proves the bank balance” | receipt is a Makronexus document; reconciliation proves the relationship to bank activity |
| “Delete the bad journal” | reverse it with an offsetting entry |
| “The same code always resolves to the same account” | school-specific account overrides tenant default |
| “Balanced trial balance means every transaction is correct” | it proves debit/credit equality, not correct classification or completeness |
Mupfure scenario
Mupfure posts a USD 300 payment.
The accountant verifies:
- the source payment ID;
- the journal date and USD currency;
- the configured bank/cash debit account;
- the configured receivable credit account;
- equal debit and credit amount;
- posted status;
- source traceability;
- no posting exception.
The accountant does not infer those account mappings from this page.
Knowledge check
- What is the source ledger in Makronexus?
- What takes precedence: tenant-default or school-specific account?
- Can a header account receive a journal posting?
- How is posted history corrected?
- Does a balanced trial balance prove all accounts are correctly classified?
Answer guide
- The internal General Ledger.
- The exact school account.
- No.
- With an offsetting reversal.
- No.