Record a balanced journal entry under period control
Learn Finance · Fund & Financial Accounting · Task B2. Make a posting that balances, carries its coding block, and lands in an open period — the atom every report is built from.
What it is
A journal entry is one accounting event, recorded as two or more lines that must sum to zero — total debits equal total credits. That's double-entry: every amount comes from somewhere and goes to somewhere.
- Debit (Dr) and Credit (Cr) aren't "plus" and "minus" — they're two sides. A debit increases an asset or expense; a credit increases a liability, income, or fund (and vice versa).
- The entry sits in an accounting period (a month). Once a period is closed, you can't post into it — the numbers for that month are frozen.
Why it matters
- Balancing is the first integrity check. An entry that doesn't sum to zero is a broken event; the ledger must refuse it, or your trial balance will never tie out.
- Period control protects reported numbers. If anyone could back-date a posting into a month already reported to a donor, every historical report becomes unreliable. The lock is what makes "the September figures" mean something.
- It's the audit trail's unit. Every entry records who posted it and when — the thread an auditor pulls.
Where you do it in VanillaPM
Everything below is in Finance → Accounting. A step-by-step:
-
Start a journal entry. Create a JournalEntry (date, description, period) and add its JournalLines — each line a debit or a credit to an account.
-
Code each line. Every line prompts for the coding block its account requires (B1) — so the entry is tagged to the right fund / donor / grant as you write it, not reconstructed later.
-
Balance it — or it won't save. Debits must equal credits. The ledger refuses an unbalanced entry, and a Postgres deferred-balance trigger enforces it at the database level, not just in the form — so an unbalanced entry can never be slipped in by any route.
-
Post into an open period. The entry lands in an AccountingPeriod; posting into a closed period is blocked (B8). Once posted, the entry is part of the permanent record — corrections are made by a reversing entry, not a silent edit.
Walked example — Hilsa Health Initiative
The INGO pays $5,000 for programme supplies from its bank account. One balanced entry:
| Line | Account | Dr | Cr | Coding block |
|---|---|---|---|---|
| 1 | 5200 Programme supplies | 5,000 | Restricted · Nordic Health Fdn · HHI-2026 · Cox's Bazar | |
| 2 | 1101 Bank | 5,000 | — | |
| Total | 5,000 | 5,000 | balances ✓ |
The expense goes up (debit), the bank goes down (credit), it sums to zero, and it's coded to the grant. If this is a grant-eligible cost, a second entry recognises the matched income (B3).
The numbers
The rule you check on every entry: Σ debits = Σ credits. If you add a third line (say $200 of the supplies was for the core office, not the grant), the split still has to balance:
Dr 5200 Supplies 4,800 (→grant) · Dr 5200 Supplies 200 (→core) · Cr 1101 Bank 5,000 → 5,000 = 5,000.
Controls & evidence
- Balanced entries only — enforced in the app and by the database trigger (defence in depth).
- Period lock — closed months are read-only; re-opening is a deliberate, logged act.
- Append-only audit trail — every entry stamped with its author and timestamp; corrections are new reversing entries, never silent edits.
- Supporting document attached (the invoice, the receipt) so the entry is evidenced.
Best practices & pitfalls
- Do write a clear narration — "what is this?" answered in one line saves everyone later.
- Do correct errors with a reversing entry, not by editing or deleting — the trail must stay intact.
- Pitfall: forcing an entry to balance by plugging a difference into a convenient account. A plug hides a real error; find the actual missing line.
- Pitfall: trying to post into last month after it's closed. If it genuinely belongs there, that's a controlled re-open decision — not a workaround.
Practise question
Q1. You try to post Dr 5100 Salaries 10,000 / Cr 1101 Bank 9,000. What happens, and why?
Answer: The ledger rejects it — debits (10,000) don't equal credits (9,000), so it isn't a
valid double-entry event. You're missing $1,000 of credits (likely tax withheld, Cr a withholding
liability — see B7). Balancing isn't a formality; the imbalance is
telling you a line is missing.
Terms used here
- Double-entry — every event recorded as balanced debits and credits.
- Debit / credit — the two sides of an entry; their effect depends on the account type.
- Accounting period — the month an entry belongs to; closing it freezes the numbers.
- Reversing entry — a new entry that undoes a prior one, preserving the trail.
- Related: Book a grant with deferral & matching — the entry pattern that defers income.
How an auditor / donor expects this
They expect a trial balance that ties (debits = credits overall), closed periods that don't move, and a trail from any figure back to a dated, authored entry with its supporting document. If a reported number can't be traced to a balanced, evidenced entry in a closed period, it isn't trusted — and VanillaPM's enforced balancing + period lock + append-only trail are exactly what make that traceability hold.