Accounting and posting

How Nyumba Zetu records double-entry journals from your property-management activity—posting rules, events, and typical account flows.

This guide explains how Nyumba Zetu turns day-to-day property-management work—tenant billing, collections, expenses, and related flows—into double-entry accounting in your ledger. It is written for operators and finance users; it is not a full accounting standards manual.

What this covers

Your organization’s books reflect what happened in the product: posted invoices, money received, payments applied to invoices, expenses, recharges to tenants, tax and retention movements, and more. Each qualifying business action can produce a journal entry (debits and credits that balance) so reports such as trial balance and P&L trace back to real activity.

Nyumba Zetu also supports owner and landlord reporting (statements, amounts due to owners). The company ledger described here is the property manager’s operational accounting; owner splits and trust-style flows may use additional allocation logic depending on your setup—see Owners and landlords and Reports.

Core principles

  • Double entry: Every journal balances: total debits equal total credits for that entry.
  • Audit trail: Journals record the financial effect of business events with references back to the source (for example an invoice or payment).
  • Accounting periods: Posting is allowed only into open periods. You cannot post into a closed (or locked) period; period controls protect reported numbers.
  • Immutability: Posted journals are not edited in place. Corrections use the product’s supported paths—such as credit notes, refunds, or other adjustments—so the history stays clear.
  • Idempotent posting: The same logical event should not create duplicate journals. The system uses a deterministic posting key so duplicate processing returns the existing journal instead of posting again.

Void, write-offs, invoice edits, and multi-part journals

  • Void — When an issued invoice is voided, the business document is nullified. In the ledger, that typically means reversing the invoice-originating journals (the receivable/revenue recognition from the invoice), following your policy — not the same as a payment or allocation entry.
  • Write-off — When a balance is written off as uncollectable, accounting usually records bad debt (or similar) while preserving the invoice history for audit. That is a different meaning from void: it does not simply “delete” the invoice posting in the same way as a void workflow.
  • Invoice edits after posting — If an invoice was already posted and you change amounts or lines that affect recognition, corrections use reversal and repost of the invoice journals (not in-place edits). Payment and allocation journals stay driven by payment flows.
  • Reconcile before you finalize — After reposting an invoice, finance processes should ensure the invoice balance still matches allocations and the subledger before treating the new posting as complete.
  • Several journals per invoice — Some setups post more than one journal for a single invoice (for example tax or segment splits). Reports and support tools should look at all related journal rows (source and posting keys), not a single “one id” shortcut on the invoice.

How posting runs

When you record an action that affects the ledger (for example posting an invoice or receiving a payment), the application emits a domain event. A background accounting consumer picks up that event, selects the correct posting action and handler, builds journal lines from the event payload (a snapshot of the data), and writes one journal through a single posting service. That keeps the ledger consistent and avoids double-counting when the same event is delivered more than once.

flowchart LR
  business[Business action in app]
  outbox[Domain event and payload]
  consumer[Accounting posting consumer]
  handler[Handler builds journal lines]
  journal[Journal entry posted]
  business --> outbox --> consumer --> handler --> journal

Chart of accounts (COA): Accounts are resolved by code for your organization (for example cash, receivables, revenue, VAT). Your administrator maintains the COA in settings; postings hit those accounts rather than hard-coded numeric IDs in application code.

Service types: For invoices (and similar), line items often map to service types so revenue and tax post to the right income and liability accounts when configured.

Posting rules in Nyumba Zetu

In this product, “posting rules” means:

  1. Posting actions — A catalog of allowed actions (for example invoice post, payment received, expense post). Each action is valid only for certain source types (invoice, payment, expense, and so on).
  2. Handlers — For each event type, a handler knows how to build balanced lines from the outbox payload (the snapshot shipped with the event), including which accounts to use.
  3. COA resolution — Accounts are looked up by account code per organization so your chart stays data-driven.

Together, these replace ad-hoc spreadsheets: the same posted invoice always produces the same accounting pattern, subject to your COA and service-type setup.

Events and typical journal patterns

The table below lists implemented flows that reach the accounting consumer. Wording is simplified; actual accounts depend on your COA and configuration.

Event (business meaning)Typical journal pattern (summary)
invoice.posted — Tenant invoice is postedDr Accounts receivable · Cr Revenue (by line/service type) and Cr VAT output where applicable
payment.received — Customer payment recordedDr Cash (bank/M-Pesa account mapped from the payment) · Cr Unapplied receipts (liability until allocated)
payment.allocated — Payment applied to invoicesDr Unapplied receipts · Cr Accounts receivable (per allocation amounts)
expense.posted — Expense approved/postedDr Expense / VAT input (by line) · Cr Accounts payable
expense.payment_recorded — Vendor payment settledDr Accounts payable · Cr Cash (and optionally withholding/retention lines when amounts apply)
tenant_recharge.created — Recharge to tenant (e.g. recoverable cost)Dr Tenant receivable (recharge) · Cr Due to landlord / owner payable
wht.remitted — Withholding tax remittedDr Withholding tax payable · Cr Cash
retention.released — Retention released to vendorDr Retention payable · Cr Cash
credit_note.posted — Credit note postedDr Revenue / Dr VAT output (reversal of recognition) · Cr Accounts receivable
refund.issued — Refund to tenantDr Unapplied receipts · Cr Cash
coa.updated — Chart of accounts changedNo journal — refreshes cached account lookups only

Events may appear in integration or audit logs under names like invoice.posted or payment.received. The exact posting action codes stored on the journal are internal identifiers used for validation and reporting.

The payables side arrived in August 2026

expense.posted and expense.payment_recorded are in the table above because they are how expenses are meant to post, and until the August 2026 release they did not. Expense categories carried no account mapping and vendors carried no ledger identity, so an expense was recorded operationally, paid, and never reached a journal. The general ledger held income and almost no cost.

Three things follow, and they matter when you compare periods:

  • Profit for earlier periods was overstated. Bringing the history in moves it, and that movement is a correction, not a new cost.
  • Statements were unaffected the whole time. Financial statements are computed from the transaction record rather than read out of the posted journal, which is why the reports looked right while the journal did not. See Financial statements.
  • Ledger and receivables are now reconciled nightly. A disagreement between what is owed and what the ledger says is owed raises a finding in Platform Health the next morning instead of being discovered at year end.

Property management in practice

Tenant billing

When an invoice is posted, the system recognizes receivables and revenue (and output VAT where lines are taxable). That matches the accrual idea: revenue and tax are recorded when the invoice is posted, not only when cash is received.

Collections

Payment received first increases cash and unapplied receipts (money received but not yet matched to specific invoices). When you allocate the payment to invoices, unapplied receipts move to accounts receivable, reducing what the tenant still owes on those invoices. This two-step pattern matches many receivables workflows.

Expenses and payables

Posted expenses recognize cost and VAT input where applicable, with a credit to accounts payable. When you pay the vendor, payables and cash settle the obligation; withholding or retention may split the credit if your process includes them.

Recharges, WHT, and retention

Tenant recharges bill the tenant (receivable) while crediting amounts due to the landlord when that is how your org books recoveries. WHT remittance and retention release move balances from liability accounts to cash when you pay tax authorities or release withheld amounts.

Owners and landlords

For owner statements, fees, and payouts, your process may combine ledger balances with allocation rules (how rent and fees split between manager and owner). Those business rules sit alongside the company journal; see Owners and landlords and Reports for where to run statements and period reports.

Recording a journal by hand

Most journals are written by the posting engine when a document posts. Where something genuinely has no document behind it — reclassifying a charge booked to the wrong account, or an adjustment agreed with your accountant — you can record one yourself.

Accounting → Journal Entries → Create.

  1. Date it and say what kind it is

    The month it lands in must still be open. Entry type is Manual or Adjustment — those are the only two, because invoice and payment journals belong to the documents that produced them.

  2. Give a reason

    It shows on the ledger. "Reclassify March water billed to the wrong account" is the standard to aim for.

  3. Add at least two lines

    Each line needs an account and an amount. Optionally attach a service type, a description, and the lease it relates to.

  4. Balance it

    Debits must equal credits before it will post.

Where to work in the app

Operational surfaces that feed the ledger: Invoices · Receiving payments · Allocations · Expenses · Refunds · Owners · Reports