How to set up Accounts, from zero.

1.1

Who this guide is for

1.2

What you'll have at the end

1.3

Five-minute vocabulary primer

2.1

What is double-entry accounting?

2.2

The setup roadmap

3.1

Logging in

Figure 3.1 — The Ragenaizer login screen. Enter the email and password you were given, then click Sign in.

3.2

Where you land: the Accounts dashboard

Figure 3.2 — The Accounts dashboard on a fresh install. Six KPI tiles at the top, a Bank Accounts strip, a Recent GL Entries table, and a grid of Quick Action cards below. Everything is empty — that's about to change.

3.3

The KPI tiles — what each number means

Figure 3.3 — The seven live KPI tiles after the demo tenant has booked a working set of invoices, bills, payments, and a bank account. Every number refreshes on page load and on the Refresh button in the header.

What each tile means, in reading order:

• Cash Position — sum of every active bank account's current balance, with a sublabel that splits Bank vs. Cash/Petty Cash so you can see how much is in a tellable account vs. in physical cash. Pulled from bank_accounts.current_balance, grouped by account_type.
• Revenue (MTD) — total revenue posted in the current calendar month, with a trend arrow in the top-right of the tile comparing against the previous month. Green up-arrow if you're ahead of last month, red down-arrow if you're behind. Computed as credit − debit on every GL line against an Income-type account in the current month window.
• Revenue (YTD) — same math but for the active fiscal year. The sublabel shows the FY name (e.g. "FY 2026-27") so you always know which window you're looking at. On a tenant with no active FY, this tile shows a dash.
• Net Profit (YTD) — Revenue YTD − Expenses YTD. Goes red if you're running at a loss. This is the single most important number senior management looks at — it's the bottom line.
• AR Outstanding — total balance_due across every customer invoice in approved, sent, partially_paid, or overdue status. Sublabel counts how many open invoices make up that total. A red OVERDUE badge appears in the corner if any of those invoices are past their due date, so you can tell at a glance whether collections is on top of things or needs a nudge.
• AP Outstanding — mirror of AR on the vendor side: what you owe vendors today across all open bills, with the same overdue badge and count sublabel.
• Projected Balance (30d) — a simple 30-day cash flow forecast. Starts from your current cash position, adds every AR balance due in the next 30 days, subtracts every AP bill due in the next 30 days, and shows what the bank is likely to look like a month from now if collections and payments run to schedule. Sublabel breaks down the inflow and outflow components so you can see whether the change is driven by money coming in, money going out, or both.

3.4

Quick Actions — every button explained

3.5

Recent activity feed

Figure 3.5 — The Recent GL Entries table on day one. By Section 10 you'll see your first row appear here.

Figure 3.6 — The same dashboard after working through every module in this guide. KPI tiles are no longer zero (Total Revenue, Total Receivable, Cash on Hand, Outstanding Bills all carry real numbers), the Recent GL Entries table shows the most recent postings from Banking, Receivables, Payables and Expenses, and the navigation cards highlight modules with new activity. This is what an investor sees when you hand them a working tenant.

4.1

Where to find Accounts Setup

Figure 4.1 — The Accounts Setup hub, before any data is entered. Sidebar tabs 1–9 on the left, content area on the right.

4.2

Tab 1 — Account Types

Figure 4.2 — The five Account Types, seeded by the system. You won't add or remove these — they're the bedrock of double-entry accounting.

4.3

Tab 2 — Account Groups

Figure 4.3a — Account Groups tab, empty. The toolbar has a Type filter, a search box, and the Add Group button.

Figure 4.3b — The Create Group modal. Five fields: Name (required), Account Type (required), Parent Group (for nesting), Code (optional, used for sorting), Description.

Figure 4.3c — The same modal with the Current Assets group filled in. Click Save.

Figure 4.3d — The Account Groups table after creating our four foundational groups. Notice the new CODE column — codes are optional but make sorting predictable.

Filter, search, and row actions

Figure 4.3e — Filter by Type set to Income. The table narrows to one row, the counter ticks 4 → 1.

Figure 4.3f — Typing Current into the search box filters to two rows (Current Assets and Current Liabilities). Clear the search to see all four again.

Figure 4.3g — Editing Current Assets — all five fields prefilled.

Figure 4.3h — The Delete confirm dialog. Notice it names the specific group and code — no ambiguity.

Figure 4.3i — What happens when you try to delete a group that has accounts under it. The error message is actionable: it tells you how many accounts are blocking the delete and what to do about it.

Figure 4.3j — The same flow when the group is empty — a green success toast names what was just deleted, and the table refreshes immediately.

4.4

Tab 3 — Accounts

Figure 4.4a — The Accounts tab on day one. Filter by Type, Filter by Group, search box, Show Inactive toggle, Import button, Add Account button — we'll exercise every one.

Figure 4.4b — The Create Account modal. Code, Name, Type, Group, Parent Account (for sub-accounts), Normal Balance, Description, Allow Direct Posting toggle.

Figure 4.4c — Cash in Hand fully filled in. Click Save.

Figure 4.4d — The Accounts table after creating our three foundational accounts. Each row has three action buttons: View (eye), Edit (pencil), Deactivate (red prohibit icon).

View, Edit, Deactivate — the three row actions

Figure 4.4e — The View modal for Cash in Hand. Read-only, no risk of accidental changes.

Figure 4.4f — The Edit modal — the same form as Create, but with all seven fields prefilled. Title flips to Edit Account.

Figure 4.4g — The Deactivate confirm. Names the target account and code, explains what deactivate does, and tells you how to undo it.

Figure 4.4h — After clicking Deactivate, the row disappears from the table by default. Notice the stat tiles: Total stays at 3, but Active drops to 2 and Inactive ticks up to 1. The success toast names exactly which account was deactivated.

Figure 4.4i — Tick the Show Inactive toggle to bring deactivated accounts back into view. The deactivated row is shown with an Inactive status badge and only two action buttons (View + Edit) — no Deactivate, since it's already deactivated.

Search and filter

Figure 4.4j — Filter by Type set to Income. The table narrows to just Sales Revenue. All three stat tiles update in sync.

Figure 4.4k — Typing Cash into the search box filters to one row.

4.5

Tab 4 — Account Tree

Figure 4.5a — The Account Tree, fully expanded. Click any chevron to collapse a branch. Use the toolbar buttons Expand All / Collapse All for the whole tree at once.

Figure 4.5b — After clicking Collapse All — only the three top-level types remain. Click any chevron to drill back in.

Figure 4.5c — The search box at the top works on the tree too — typing cash filters down to the matching branch and keeps its parent context visible.

5.1

Tab 6 — Fiscal Years

Figure 5.1a — Fiscal Years tab on day one.

Figure 5.1b — The Create Fiscal Year modal — just three fields: Name, Start Date, End Date.

Figure 5.1c — Filled in for FY 2026-27.

Figure 5.1d — The Fiscal Years tab after saving. The active year is highlighted in the middle stat tile. Each row has two action buttons: View (read-only details) and Close Year.

Figure 5.1e — The View modal shows every field including Created At, Active Yes/No, and Closed Yes/No.

5.2

Tab 7 — Fiscal Periods

Figure 5.2a — All twelve periods for FY 2026-27. Each starts as Open. The single action button is Lock.

Figure 5.2b — The Lock Period confirm dialog. It names the specific period and explains exactly what locking means — existing entries are not affected, only new ones are blocked.

What happens when you post into a locked period

Let's prove the lock actually does something. Flip to the General Ledger page, click Create Entry, and try to save a balanced journal entry dated inside a locked period. The front-end form will happily let you fill it in — the check happens at the API layer, not the client — so the real moment of truth comes when you click Save as Draft. The backend looks up the fiscal period that contains entry_date, sees is_locked = true, and returns an HTTP 409 Conflict with a targeted message:

HTTP/1.1 409 Conflict
{
  "error": "Cannot create entry in locked period 'Dec-2026'"
}

The same rule applies everywhere a GL entry would be posted: approving a customer invoice dated inside a locked period, approving a vendor bill, recording a bank transaction — every single write path goes through the same CheckPeriodLocked guard in BusinessLayer_Fiscal, so it's impossible to sneak a past-dated entry into a closed month through the UI or the API. The front-end surfaces the backend error as a toast.

Demo: lock a future period and watch the badge flip

You should not lock the current month mid-month — live transactions are still landing in it — so for demo purposes we'll lock a period that's safely in the future (say Dec 2026) and then unlock it so the books remain exactly as we started.

Figure 5.2c — Fiscal Periods tab baseline for FY 2026-27. Every row shows Open status with a Lock action button. We'll lock Dec-2026 for this demo.

Figure 5.2d — Click Lock on the Dec-2026 row. The confirm dialog names the target period explicitly and describes the consequence: "This will prevent new entries from being posted in this period. Existing entries will be unaffected. Continue?" The primary action button says Lock (not a generic "OK"); click it to proceed.

Figure 5.2e — After confirming: the Dec-2026 row's status badge flips from Open (green) to Locked (red), and its action button changes from Lock to Unlock. The other eleven periods are still open. Clicking Unlock on the locked row reverses the state — same confirm pattern, inverted label — and brings it back to Open. Both actions are audit-logged (entity_type = fiscal_period, action = locked or unlocked), so you can always see who locked what and when in the Audit Logs tab.

5.3

Tab 8 — Journal Types

Figure 5.3a — The Journal Types tab with six seeded system types and one custom type. Notice the action column — system types only have View; the custom type also has Edit and Delete.

Figure 5.3b — The Create Journal Type modal. Three fields: Code (a short uppercase identifier), Name, Description.

5.4

Tab 9 — COA Templates (the shortcut)

Figure 5.4 — The COA Templates tab. Two buttons, one warning. Run the template only once — running it twice creates duplicates.

6.1

Open the Taxation page

Figure 6.1 — The Tax Configs tab with our GST 18% config already created. Notice the Seed India GST button on the right — that's the shortcut for production setup.

6.2

Tax Config Detail (View modal)

Figure 6.2 — The Tax Config Details modal. Two-column grid for primary fields, full-width Description and Configuration JSON below.

6.3

Tab 2 — Tax Rates

Figure 6.3 — The Create Tax Rate modal — Name, Rate %, Tax Config (parent), Account, Status. For India GST you'd typically create three rates for each config: CGST, SGST, IGST.

6.4

Tab 3 — HSN/SAC Codes

Figure 6.4a — Creating SAC code 9983 for professional services at 18%.

Figure 6.4b — The saved code in the table. Once you have at least one HSN/SAC code, the Customer Invoice line item will let you pick from this list.

7.1

The Opening Balances tab

Figure 7.1 — The Opening Balances form on day one. Three accounts, six empty cells, totals row reading ₹0.00 / ₹0.00 with the helpful prompt to enter values.

7.2

Filling in a balanced set

Figure 7.2 — The form with both sides filled in. Notice the live totals and the green status text. If the two sides don't match, the status flips red and tells you exactly which side is over and by how much.

7.3

Saving and what happens behind the scenes

Figure 7.3 — After saving, the page reloads with the values prefilled. Notice the new 3300 Current Year Earnings row that the system auto-created — that's where the contra entries land.

8.1

Open Vendors & Customers

Figure 8.1 — The Vendors & Customers page. Two-tier sidebar — Vendors above, Customers below — each with a List view and a Pending Approvals view.

8.2

Adding a customer end-to-end

Figure 8.2a — The Create Customer modal fully filled in. Click Save.

Figure 8.2b — After save, Lumira appears as C-001 in the Customer List. The customer code is auto-generated. Total / Active / Inactive stat tiles update.

9.1

Adding a vendor

Figure 9.1a — The Create Vendor modal, empty. Twenty fields including the bank section at the bottom.

Figure 9.1b — Filled in for CloudKite.

Figure 9.1c — After save — vendor appears as V-001. The Pending Vendors counter stays at 0 because admins are auto-approved; non-admin users go through a moderation queue.

10.1

Open Accounts Receivable

Figure 10.1 — The Receivables landing page on day one. Four stat tiles (Total / Draft / Approved / Total Receivable), filter toolbar, and the empty invoice table.

10.2

Creating an invoice

Figure 10.2a — The Create Invoice modal, blank. The Line Items grid starts with one empty row — click + Add Line for more.

Figure 10.2b — Filled in. Subtotal ₹1,00,000, no tax, total ₹1,00,000. Three save buttons at the bottom: Cancel, Save Draft, Save & Approve.

10.3

Save Draft → Approve

Figure 10.3a — The new invoice INV-2026-00001 in Draft status. The action column has Edit and Approve buttons.

Figure 10.3b — The same invoice after Approve. The action column now has Edit and Send buttons. The receivable balance has appeared on the right-hand stat tile.

Click Send on the row to demonstrate the next state transition.

Figure 10.3c — The Send confirm names the target invoice and customer in full: "Mark INV-2026-00001 to Lumira Studios LLP for ₹1,00,000.00 as Sent? This records that the invoice has been delivered to the customer (typically by email). The status flips to Sent and the action column updates accordingly. This action does not post anything to the ledger." Cancel to keep the row in Approved state for the rest of the walk-through.

10.4

Tour the other Receivables tabs

Figure 10.4a — Customer Payments tab. Empty until you record a payment. The Record Payment form requires Customer, Invoice (filtered to that customer's approved invoices), Amount, Bank Account, and Reference. On save it posts Dr Bank / Cr Accounts Receivable and clears the matching invoice's open balance.

Figure 10.4b — Credit Notes tab. Used when you need to refund or write off part or all of an invoice. The flow mirrors invoice creation but in reverse: pick the customer, link the original invoice, enter line items, and on approval the system posts Dr Sales Returns / Cr Accounts Receivable.

Figure 10.4c — AR Aging report. Shows every customer's outstanding balance in five buckets (Current, 1–30, 31–60, 61–90, 90+ days). The Lumira invoice is in the Current bucket because it was approved today. As time passes without payment, balances roll into older buckets — that's how you spot collection problems before they hurt cashflow.

Figure 10.4d — Customer Statements. Pick a customer and a date range to generate a per-customer statement listing every invoice, payment, and credit note in that window with running balance. Email it to the customer with one click on the toolbar.

Customer Payments — view only, correct via credit note

Once you have a few customer payments recorded, the Customer Payments tab shows one row per payment with date, customer, invoice, amount, bank account, reference, and a single View action.

Figure 10.4e — Customer Payments populated with 2 rows (SkyBridge Networks and Acme Corp). Each row has only a View icon — no Edit and no Void. The asymmetry with Vendor Payments (which has Void) is deliberate: if you recorded a customer payment incorrectly, the accounting-correct fix is to issue a credit note against the original invoice, not to delete the payment. A credit note:

• Leaves the original payment intact (so the bank reconciliation against the actual bank statement is still sound).
• Creates a visible offsetting entry with a clear reason and line items describing the adjustment.
• Can be partially applied (only a portion of the invoice was wrong) or fully applied (the whole invoice is being cancelled).
• Reduces the customer's outstanding balance by the credit amount.

Concretely: suppose you recorded a ₹50,000 payment from Acme Corp against INV-2026-00020, but the customer actually sent only ₹5,000 — the extra ₹45,000 was a typo. Don't void the payment. Instead:

1. Go to Credit Notes tab (§10.4b).
2. Create a new credit note, customer = Acme Corp, linked invoice = INV-2026-00020, amount = ₹45,000, description = "Overpayment correction — typo in original payment entry".
3. Approve the credit note — the system posts Dr Sales Returns / Cr Accounts Receivable, clearing the ₹45,000 from the customer's AR balance.
4. The customer statement now shows INV-2026-00020 (₹50,000), PAY-2026-00015 (₹50,000 against it), and CRN-2026-00003 (₹45,000 credit against it) — net balance ₹45,000 in customer's favour, to be applied against their next invoice or refunded to their bank account with a manual journal.

10.5

Late payment reminders — automatic and manual

The two automatic jobs

Two recurring Hangfire jobs are registered at startup and run every day regardless of whether you have the UI open:

• before-due-reminders — 09:00 server time. Finds every approved / sent invoice where due_date = CURRENT_DATE + 3 days and sends a friendly "your invoice is due in 3 days" reminder to the customer's billing contact. This is the "nudge" email — tone is polite, assumes the customer intends to pay.
• overdue-invoices — same job that flips invoices to overdue status at 06:00 each morning. After the status flip it iterates every newly-overdue row and fires a follow-up reminder. The tone escalates with days overdue:
  • on_due (0 days) — friendly reminder, "just a heads-up, today is due date".
  • overdue_7 (1–7 days late) — firm but still friendly, "we haven't received payment, can you confirm the payment date?".
  • overdue_15 (8–15 days late) — serious, "this invoice is now 15 days past due; please remit immediately or contact us to discuss a payment plan".
  • overdue_30 (16+ days late) — final-notice language, "failure to respond within 7 days may result in escalation".

The manual Send Reminder button

For when "tomorrow morning's auto-run is too far away". Every invoice row in the Receivables → Invoices table now has a bell-icon Send Reminder action alongside the existing View, Download PDF, and Pay buttons. It appears only on invoices in statuses where a reminder is meaningful: approved, sent, partially_paid, and overdue. Draft invoices don't get the button (nothing to remind about) and paid invoices don't either (nothing owed).

Figure 10.5a — The Invoices list with the new bell-icon Send Reminder action visible on every row where the customer still owes money. Status-aware: the button only renders for approved / sent / partially_paid / overdue; draft and paid invoices don't get it. PDF download and Pay still work as before.

Click the bell icon on any open invoice.

Figure 10.5b — The Send Payment Reminder confirm. Target invoice is named in the message and the primary button says Send Reminder (not a generic "OK"). Click it to send immediately; click Cancel to back out. The send lands in the backend SendInvoiceReminder business-layer method which: (1) fetches the invoice + customer, (2) refuses if the invoice is paid / cancelled / written-off or has zero balance, (3) calls the notification service to dispatch the email, (4) inserts a row into invoice_reminders with reminder_type = 'manual' and sent_by = <your user id>, (5) emits an audit log entry.

Reminder history API

Every send (automatic or manual, success or failure) writes one row to invoice_reminders tagged with the invoice, the reminder_type, the user (NULL for automatic runs), the recipient email, the subject line, and a success boolean + optional error message. You can query the full history for a specific invoice via GET /api/accounts/invoices/{id}/reminders. For audit purposes the audit log (§15.5) also captures every send under entity type customer_invoice with action reminder_sent.

11.1

Open Vendor Bills

Figure 11.1 — Vendor Bills landing page. Empty on day one.

11.2

Creating a bill

Figure 11.2 — The Create Vendor Bill modal fully filled in. Same three buttons as the invoice modal: Cancel, Save Draft, Save & Approve.

11.3

Approve and watch the GL

Figure 11.3 — The bill BILL-2026-00001 in Approved state. The action column now shows a Pay button — that's how you record a payment against the bill (covered in the Payments tab).

Figure 11.3a — The Bills list with our row visible. The action column has View / Edit / Pay / Cancel for an Approved bill, and Edit / Approve / Cancel for a Draft. Both Cancel and Pay use target-named confirmation dialogs.

Figure 11.3b — The View modal opens read-only with the full bill: vendor, dates, line items, totals, and the linked GL entry. Useful when you need to confirm a posted bill's details without risking accidental edits.

11.4

Tour the other Payables tabs

Figure 11.4a — Vendor Payments tab. Empty until you pay a bill. The Record Payment form takes Vendor, Bill (filtered to that vendor's approved bills), Amount, Bank Account, Reference. On save it posts Dr Accounts Payable / Cr Bank and clears the matching bill's outstanding balance.

Figure 11.4b — AP Aging report — the mirror of AR Aging, but for what you owe instead of what you're owed. The CloudKite bill sits in the Current bucket because it was just approved. As time passes, items roll into older buckets — if your AP aging stays clean (everything in Current), you're paying suppliers on time.

Figure 11.4c — Vendor Statements. Pick a vendor and a date range to generate a running statement of bills, payments, and credit notes. Use it to reconcile with the vendor's own records before signing off on monthly accounts.

Voiding a vendor payment — the full reversal

Three things are guaranteed to happen in real life: vendors send duplicate invoices, you pay the wrong one, and by the time you notice it the payment is already posted. The Void Payment action on each row in the Vendor Payments list undoes the entire posting in one click, cleanly and reversibly, without deleting anything that would disrupt audit trails.

Figure 11.4d — The Payments tab listing all recorded vendor payments. Each row has a red circle-slash Void action in the Actions column. Clicking it does not just delete the row — it triggers a full transactional reversal across four tables (vendor_bills, vendor_payment_allocations, gl_entries, bank_accounts). See bug #57 in _BUGS_FIXED_DURING_CAPTURE.md for the motivation: the pre-fix version of this feature soft-deleted the payment row but left the ledger, bill balance, and bank account completely untouched — classic silent-books-corruption bug.

Figure 11.4e — The Void Payment confirmation. Red destructive style that names the specific payment being reversed. Click Delete (yes, the button label is a current UX nit — it should say Void to match the action — tracked in the bug log as a consistency fix) to execute the full reversal.

What the reversal actually does (in one atomic transaction)

When you confirm the Void, the backend runs all of the following inside a single database transaction. Either every step succeeds or none of them do — there is no half-voided state:

1. Reads every vendor_payment_allocations row for this payment to find which bills and how much of each bill it paid.
2. For each allocated bill: subtracts the allocated amount from the bill's paid_amount, adds it back to balance_due, and recomputes status — if the bill is now back to fully unpaid it flips from paid or partially_paid back to approved.
3. Looks up the original GL entry that the payment created (journal type BANK, ref_type vendor_payment), and posts a mirror reversing entry — same lines, same amounts, debits and credits swapped, ref_type reversal, description "Reversal: Void payment PAY-…". The original entry's is_reversed flag flips to true, so it still appears in the GL but is visibly marked as reversed and ignored by the Trial Balance calculations.
4. Updates the bank account balance by +amount to undo the original -amount. Your HDFC balance goes back to exactly what it was before the payment.
5. Deletes the allocation rows (they no longer point to real money). The parent vendor_payments row stays in the database but is soft-deleted via is_active = false — so the audit history survives, but queries like GET /payments filter it out.
6. Writes one audit-log entry for the void with allocations_reversed count and the operator's user ID.

The end state: the books are exactly where they were before the payment was ever recorded. The bill is back to Approved, the bank balance is back to pre-payment, the GL shows both the original entry and its mirror reversal so a reviewer can see the full history. Trial Balance still balances to the paisa because the two GL entries net to zero. Audit log keeps every hop.

11.5

Purchase Orders — the pre-bill lifecycle

Open Accounts → Purchase Orders from the dashboard. The demo tenant ships with eight POs across every status so you can see the full spectrum without creating new data.

Figure 11.5a — Eight purchase orders across six statuses. Stats row at the top breaks them down: Total 8 · Draft 1 · Approved 2 · Sent 2 · Received 1 · Billed 1 plus ₹3,04,000 combined value. The status badges tell you at a glance where each PO is in the pipeline: green for active-in-flight, yellow for pending action, grey for terminal.

The six-state lifecycle

1. Draft — the PO exists but can still be edited freely. No commitment to the vendor yet. Delete is allowed.
2. Approved — an authoriser (typically a manager) has ticked the approve button. The PO is locked down; fields can no longer change. Ready to be sent.
3. Sent — you've clicked Send, which in a real deployment emails the vendor a formatted PDF of the PO. In the demo, it just flips the status flag. The vendor is now on the hook to deliver.
4. Partially Received — you got some of the ordered items but not all. The received-quantity column updates line-by-line and the status moves to this intermediate state until all lines are fulfilled.
5. Received — every line is received in full. You can now generate a vendor bill from it.
6. Billed — you clicked Convert to Bill on a received PO. A new vendor bill row is created with the same vendor, lines, amounts — and, crucially, a back-reference to the originating PO. From here the bill follows the normal vendor-bill lifecycle (section 11.2).

A seventh state, Cancelled, is a terminal off-ramp — you can cancel a PO in any state before it becomes Billed. The demo data shows PO-2026-00007 in this state.

Creating a new PO

Click + Create PO. The form is wider than most because it includes the line-items grid inline.

Figure 11.5b — The empty Create Purchase Order modal. Header fields: Vendor, PO Date, Expected Date, Currency, Notes. Below that, the Line Items section with inline rows — each row needs Description, Account (GL expense), Qty, Unit Price, and computes Amount live. Click + Add Line to append more rows; the X on the right of each row removes it. Totals for Subtotal, Tax, and Grand Total update as you type.

The View modal — the source of truth

Click the View (eye) icon on any row to open a read-only detail modal. It's the same layout as the create modal but with every field disabled, plus it shows the PO number, its current status badge, and the final computed total. Use it when you need to reference a PO's details without risk of accidentally editing. It's also what the Send PO action renders internally before formatting the outgoing email.

Figure 11.5c — The View modal for PO-2026-00002, an existing Received PO from DataPipe Networks for ₹24,000. Status badge at the top right, one line item (AS Service Aid mapped to 1170 Prepaid Expenses), PO date + expected date inline. At the bottom right: Send and Close buttons. Because this PO is already in received status, a Convert to Bill option is also available in the row's action menu in the list view — clicking it creates a vendor bill pre-populated from this PO.

Converting to a bill — where the GL finally wakes up

A PO posts zero GL entries — it's a pure document. The moment financial reality catches up is when you click Convert to Bill on a received PO. This action:

1. Creates a new row in vendor_bills with po_id set to the source PO (so you can always trace back).
2. Copies the vendor, every line item (description, account, quantity, rate, amount, tax), and the totals over to the new bill.
3. Leaves the bill in Draft status so the AP clerk can still edit it if the vendor's invoice doesn't exactly match the PO (a common case — rate adjustment, partial shipment, tax calculation difference).
4. Flips the source PO's status from received to billed (the terminal non-cancelled state).

From here the bill follows the normal AP lifecycle (sections 11.2–11.3): approve, post the GL entry (Dr Expense / Cr Accounts Payable), record payment when money leaves the bank. The PO becomes the audit anchor that links "we ordered this" to "we received this" to "we were billed this" to "we paid this" — all four events connected through stable foreign keys, not manual filing.

12.1

The GL Entries page

Figure 12.1 — The GL Entries page after our four transactions. Sortable filters across the top: date range, account, journal type, status, source, free-text search.

Figure 12.1a — The same page after we've also worked through Banking and Expenses — deposits, withdrawals, transfers, the interest credit, the expense claim approval and the reimbursement. Every operational click in the other modules ends up as a row here, with the Source column showing where it came from (Bank Transaction, Bank Transfer, Expense Claim, Customer Invoice, Vendor Bill). Use the Source filter to slice by where entries originated.

12.2

The GL Entry Detail modal

Figure 12.2 — The GL Entry Detail for the CloudKite bill posting. Two lines, both ₹12,000, balanced.

12.3

The Journal Entries tab and reversing an entry

Figure 12.3a — Journal Entries tab. Same underlying data as GL Entries but the action column has the four month-end controls. The Journal Type filter at the top lets you see only Sales, only Purchases, only Bank, and so on.

Figure 12.3b — Clicking Reverse opens a target-named confirm: "Reverse GL-2026-XXXXX (Bank Transaction, ₹3,000.00) by posting a mirror entry dated today? The original entry stays in the ledger; a new GL entry is created with debits and credits swapped, so net effect on every account returns to zero. This is the audit-safe way to undo a posted entry — you never delete history." Cancel to keep the demo data.

13.1

Trial Balance — the sanity check

Figure 13.1 — The Trial Balance for FY 2026-27. Six accounts, debits = credits = ₹1,62,000, with the green confirmation "Trial Balance is balanced" at the bottom.

Figure 13.1a — The Trial Balance regenerated after we've worked through Banking and Expenses too. More accounts now: HDFC Bank, ICICI Bank, Reimbursement Payable, Sales Revenue, Interest Income, Travel Expense, Office Rent Expense, Accounts Receivable, Accounts Payable. Debits and credits still match exactly. This is the single most reassuring number in accounting — if Trial Balance ever stops being balanced, your double entry has broken somewhere and you stop everything until you find it.

13.2

Profit & Loss (with year-over-year comparison)

Figure 13.2 — The P&L for FY 2026-27. Revenue ₹1,50,000 (the opening Sales balance + the Lumira invoice) minus Office Rent ₹12,000 = Net Profit ₹1,38,000.

Comparative mode — "Compare to"

A raw P&L tells you what this year looks like. A comparative P&L tells you whether that's good or bad relative to the period you care about. In the toolbar above the report there's a Compare to dropdown with three options: None (the default, backward compatible with every prior use of the report), Previous Year (same date range shifted back one year — this is the most common view for annual reviews), and Previous Period (the immediately preceding window of the same length — useful for month-over-month trend analysis).

Figure 13.2a — The reports toolbar with the new Compare to dropdown right next to the fiscal year dropdown. Default is None so the existing one-column view still works without any user action; switching to Previous Year or Previous Period is what unlocks the comparison columns.

Select Previous Year and click Generate. The report refreshes with six columns instead of the usual two: Code, Account Name, Current, Comparison, Variance, Variance %. Every variance cell is colored direction-aware — green when it's favorable (income up, expense down), red when unfavorable.

Figure 13.2b — P&L for FY 2026-27 compared to FY 2025-26. Every row shows both windows side-by-side with signed variance and percentage. Where the prior-year balance was zero (new account or account that didn't exist last year), the Variance % column shows NEW in the same direction-aware color — green for a new income account (good news: new revenue stream), red for a new expense account (new cost to watch). The banner at the top states the exact comparison window: "Comparison: 01 Apr 2025 – 31 Mar 2026".

13.3

Balance Sheet (with point-in-time comparison)

Figure 13.3 — Balance Sheet for FY 2026-27. Assets (₹1,50,000) = Liabilities (₹12,000) + Equity (₹1,38,000). The system tells you so explicitly at the bottom.

The Balance Sheet has the same Compare to dropdown as the P&L (see §13.2). The difference is in what the comparison window means for a point-in-time report: Previous Year shifts the as-at date back exactly 12 months (for the most common year-over-year view), and Previous Period shifts it back exactly 1 month (useful for catching month-over-month drift).

Figure 13.3a — Balance Sheet with Previous Period selected — "Comparison: 11 Mar 2026". Six columns: Code, Account Name, Current, Comparison, Variance, Variance %. The current-date assets are all new since last month (we set up the demo tenant in April), so every row shows NEW in the Variance % column. In a live tenant you'd see signed percentages (e.g. "+12.3%" for a growing receivable, "-4.7%" for a shrinking loan balance).

13.4

Cash Flow

Figure 13.4 — The Cash Flow statement on day one of trading. Activities are listed but all amounts are ₹0 because no cash has actually moved yet.

13.5

AR & AP Aging — "who owes us, who do we owe"

Figure 13.5a — Accounts Receivable Aging. Lumira's ₹1,00,000 sits in the Current column because we just invoiced them yesterday.

Figure 13.5b — Accounts Payable Aging. CloudKite's ₹12,000 sits in Current.

14.1

Audit Logs — "who did what, when"

Figure 14.1 — The Audit Logs feed after this session. Each row shows the timestamp, the entity type (vendor_bill, customer_invoice, customer, vendor), the action (created, approved), the user ID, and a JSON snippet of the changes. Use the filter toolbar at the top to narrow by entity type, date range, or user.

14.2

Other Administration tabs — one-line tour

14.3

Closing Checklists — the standardised month-end protocol

Figure 14.3a — The Closing Checklists tab under Administration. One checklist per period; here we have one Month End checklist for Apr-2026 currently in In Progress status. The row shows the period's fiscal year, the close type, the status, and a count of completed-vs-total items as a progress indicator. Toolbar: + Create Checklist and a fiscal-year filter.

Figure 14.3b — The Checklist Detail modal. 14 standard items, each a one-line task with a status badge — Done (green), Pending (yellow), Skipped (grey). Items cover: verify all invoices posted & approved, verify all bills received, verify bank reconciliation, run depreciation, clear suspense, review tax/TDS, review accruals, review prepaid amortisation, review payroll, review inter-company entries, close out drafts, lock fiscal period, generate closing reports, sign-off. You can tick items one-by-one with the checkbox on the left — each toggle is audit-logged with the timestamp and user, so reviewers can see exactly who signed off on what.

Figure 14.3c — The Create Closing Checklist modal. Four fields: Checklist Name (free-form label like "Apr-2026 Month End"), Fiscal Year, Closing Type (Month End / Quarter End / Year End — determines the default item template), and Description. Clicking Save creates a new in-progress checklist with all items defaulted to Pending, ready for the closing team to work through.

14.4

Year-End Closing — the once-a-year procedure

Figure 14.4a — The Year-End Closing page before anything is selected. Prominent warning at the top: "Close a fiscal year to prevent further modifications. This will lock all periods and carry forward balances. This action cannot be undone." A single Select Fiscal Year dropdown is the only input.

Pick the fiscal year you want to close. The page runs its pre-flight checks immediately.

Figure 14.4b — Pre-Flight Checks for FY 2026-27. Three hard checks: TB Balance (Dr = Cr) — the total debits in the GL must equal total credits to the paisa (if they don't, the books are already inconsistent and closing would freeze that inconsistency forever); Account Balance Drift — the cached account_period_balances must agree with the live sum from gl_entry_lines for every account (otherwise the cached reports are lying about the true position); Period Balance Consistency — every fiscal period's cached aggregate must match its GL sum. All three passed here, so the Close Fiscal Year button below is enabled. If any check had failed, the button would be disabled and the offending row would be red with a drill-down explanation.

With pre-flight green, click Close Fiscal Year.

Figure 14.4c — The Close Fiscal Year confirmation — a red destructive warning that names the target fiscal year and spells out the three things that are about to happen: (1) all twelve periods in the year get locked, (2) Revenue and Expense accounts are zeroed out by a system-generated closing JE that debits Revenue / credits Expenses / plugs the difference into 3300 Current Year Earnings, (3) the closing balance of 3300 Current Year Earnings rolls into 3200 Retained Earnings. This action CANNOT be undone. Click Close Year to commit.

What the system does behind the scenes

When you click the red button, the backend runs all of the following inside a single database transaction:

1. Re-runs the three pre-flight checks (just in case anything changed between loading the page and clicking the button).
2. For every Revenue account with a non-zero balance, creates a closing journal line: Dr Revenue for the full balance, Cr 3300 Current Year Earnings.
3. For every Expense account with a non-zero balance, creates the mirror: Dr 3300 Current Year Earnings, Cr Expense for the full balance.
4. Posts the aggregate closing JE (journal type CLOSING, entry date = fiscal year end date, description = "FY 2026-27 Year-End Closing").
5. Rolls 3300 Current Year Earnings into 3200 Retained Earnings with a second JE (Dr 3300 / Cr 3200 for the net profit, or Dr 3200 / Cr 3300 for a net loss).
6. Locks all twelve fiscal periods by setting is_locked = true.
7. Flips the fiscal year row's is_closed = true.
8. Creates the next fiscal year (e.g. FY 2027-28) with the just-computed Asset / Liability / Equity closing balances as opening balances in the new year. Revenue and Expense accounts start at zero, as they should — they're period accounts.
9. Logs every step to the audit log under entity_type = 'fiscal_year', action = 'closed'.

If any step fails, the entire transaction rolls back — you end the click exactly where you started, with a toast-level error identifying which step failed. There is no half-closed state: either the year is fully closed and the next year is fully created, or nothing happened.

14.5

Period close vs. year-end close — the distinction in one paragraph

15.1

Banking

The four tabs

The Banking module has four sub-pages in the left sidebar: Bank Accounts (the list of your physical banks), Transactions (the running ledger of every deposit and withdrawal for a selected account), Inter-Bank Transfer (a shortcut for moving money between your own accounts), and Reconciliation (month-end statement matching). We'll walk them in order.

Figure 15.1.1 — Day one: zero bank accounts. Stats tiles at the top (Total Accounts, Total Balance, Active Accounts) are all zero. Click + Add Bank Account to start.

Tab 1 — Bank Accounts

Click + Add Bank Account. The form has nine fields: Account Name (a human-friendly label like "HDFC Current A/C"), Bank Name (e.g. "HDFC Bank"), Account Number, Account Type (Bank / Cash / Petty Cash / Payment Gateway), IFSC Code, SWIFT Code (for international transfers), Branch, GL Account (the Current Asset account you created in the prep step above — e.g. 1010 HDFC Bank — Current A/C), and Set as default account (for payment modals across the app to pre-select this one).

Figure 15.1.2 — The empty Add Bank Account modal. All nine fields are visible in a two-column layout. Account Name and Bank Name are the only required fields — the rest are optional but you should fill them in anyway, because they show up on payment vouchers and bank reconciliations later.

Figure 15.1.3 — The same modal filled in for our first bank. Notice GL Account is set to 1010 — HDFC Bank — Current A/C, which is the dedicated GL account we created in the prep step. Set as default account is ticked because this is the account we'll use for most payments.

Figure 15.1.4 — After Save: one row in the table, Total Accounts=1, Active=1. The HDFC row shows a Default badge next to its name, and the three action buttons in the Actions column: View (eye), Edit (pencil), Deactivate (red circle-slash). We'll exercise all three in a moment.

Add a second account to see contrast. Click + Add Bank Account again and fill in a different bank (we used ICICI Bank — Savings A/C mapped to GL 1020). Leave Set as default unticked so HDFC stays the default.

Figure 15.1.5 — Two bank accounts, HDFC marked Default. Stats tiles now show 2 total, 2 active. This is our steady state — we'll record transactions against both accounts below.

View, Edit, Deactivate — the three row actions

Click the View (eye) button on the HDFC row. A read-only modal opens with every field you entered, the Save button hidden, and Cancel replaced with Close. View is safe to click at any time — it never mutates anything.

Figure 15.1.6 — The View modal. All fields are disabled (grey), and only a Close button in the footer. Use this when you need to quickly reference an account's details without risk of accidentally editing.

Click Edit (pencil). The same modal opens but in edit mode — every field pre-filled and editable. This is where you'd fix a typo in the IFSC, or add the SWIFT code you forgot the first time.

Figure 15.1.7 — The Edit modal, pre-filled with the saved HDFC row. Change any field and click Save Account — the row in the table updates live.

Click Deactivate (red circle-slash) on the ICICI row. A confirmation dialog appears, and crucially it names the target: "Are you sure you want to deactivate ICICI Savings A/C at ICICI Bank?" This is deliberate: confirmation dialogs across this module always name what you're about to do. If you ever see a generic "Are you sure?" prompt, it's a bug — report it.

Figure 15.1.8 — The Deactivate confirmation. Note the full message: "…It will be hidden from new transactions, transfers, and reconciliations, but its history (posted transactions, GL entries) stays intact. You can reactivate it later." — exactly what you need to know before clicking the red button.

Figure 15.1.9 — After confirming: ICICI is gone from the default list, stats drop to 1 active. To see it again, toggle Show Inactive on the top right.

Figure 15.1.10 — Show Inactive toggled ON: ICICI reappears with an Inactive badge and the Deactivate button is replaced by a Reactivate button. Click Reactivate to bring it back.

Figure 15.1.11 — Back to both rows Active. Deactivate and reactivate are completely non-destructive — no data is ever lost. Use them liberally when you close an old bank account without losing the history.

Tab 2 — Transactions

Click Transactions in the sidebar. This page is a bank passbook view, but unlike a real passbook the numbers you see are the numbers in your ledger (asset perspective) — so a deposit is a Debit (your asset goes up) and a withdrawal is a Credit (your asset goes down). If you're used to reading bank statements the other way round, this takes 30 seconds to get used to, and it's consistent with every other report in Ragenaizer. See the callout at the end of this subsection for the full explanation.

Figure 15.1.12 — The Transactions tab on first load. You must pick a bank account from the filter dropdown before anything shows — this page is always scoped to a single bank.

Figure 15.1.13 — The bank filter dropdown open, showing our two accounts. Pick HDFC Current A/C.

Figure 15.1.14 — HDFC selected but no transactions yet. Click + Record Transaction to add the first one.

Record a deposit of ₹25,000 from a customer. The Record Transaction modal has six fields: Transaction Date, Transaction Type (four manual types: Deposit, Withdrawal, Interest, Charges — transfers and payment-gateway entries are created from their own dedicated forms so the dropdown stays clean), Amount, Counter Account (the other side of the double-entry — for a customer payment this is Sales Revenue or Accounts Receivable depending on whether the invoice was approved first), Description, and Reference Number (the cheque number, NEFT reference, etc.).

Figure 15.1.15 — Empty Record Transaction modal. Date defaults to today; everything else is blank.

Figure 15.1.16 — Deposit of ₹25,000 filled: Transaction Type=Deposit, Counter Account=4001 Sales Revenue, Reference NEFT-20260405-001. Click Save Transaction.

Figure 15.1.17 — After save, the row appears in the table. Debit column shows ₹25,000 (your bank asset went up), Credit is dash, Balance shows the running total ₹25,000. Behind the scenes, a journal entry has been posted to the GL: Dr 1010 HDFC ₹25,000 / Cr 4001 Sales Revenue ₹25,000. Flip to the General Ledger page in a new tab and you'll see it.

We're going to peek at the GL right now, because this is the moment the double-entry magic becomes visible. Open Ledger → GL Entries in a new tab, find the row that just got posted, and click the eye icon.

Figure 15.1.17a — The GL Entry detail modal. Header shows the entry number, date, source ("Bank Transaction"), and the linked source document. The body shows the two postings side by side: Debit 1010 HDFC Bank ₹25,000.00 and Credit 4001 Sales Revenue ₹25,000.00. Totals at the bottom: Total Debits ₹25,000.00, Total Credits ₹25,000.00, balanced. This is the proof that one click in the bank tab created two postings in the ledger — you didn't write a single line of debit/credit by hand.

Now record a withdrawal — ₹3,000 for office rent — to show the opposite direction.

Figure 15.1.18 — Withdrawal of ₹3,000 filled: Counter Account is 5001 Office Rent Expense, Reference CHQ-445601.

Figure 15.1.19 — Two rows now. Newer transactions are at the top by default. The withdrawal shows ₹3,000 in Credit, Balance drops to ₹22,000. The running balance is computed client-side from the filtered list; if you narrow the filter, the running balance reflects only the visible subset — so don't confuse it with the absolute account balance when filters are applied.

Exercise the search and delete actions to round out the tour.

Figure 15.1.20 — Searching for "rent" narrows the table to just the Office Rent row. Clear the search to bring back everything.

Figure 15.1.21 — The Delete Bank Transaction confirm names the full target: "the Withdrawal of ₹3,000.00 on 07 Apr 2026 'Office rent — April 2026, partial advance to landlord'" — no ambiguity. Reconciled transactions cannot be deleted — you'll need to unreconcile first, which protects audit integrity. Click Cancel to keep the demo data; we need it for reconciliation later.

One more transaction type, because it shows that both sides of the entry can be inflows when the money came from outside your operations: bank interest. Pick Interest from the Type dropdown, enter ₹150 with counter account 4900 Interest Income, and save.

Figure 15.1.21a — Record Transaction modal with Type=Interest, Amount ₹150, Counter Account 4900 Interest Income, Reference INT-Q1-2026, Description "Quarterly savings interest from HDFC". Notice that for both Deposit and Interest the counter account is an income/revenue account — the difference is semantic (operating revenue vs. non-operating income) and shows up correctly on the P&L.

Figure 15.1.21b — Interest row appears at the top with ₹150 in Debit (your bank asset rose) and a fresh running balance. Cross-check on the P&L: 4900 Interest Income now shows ₹150 under Other Income, separate from Sales Revenue. That's the entire reason the GL has account types in the first place.

Tab 3 — Inter-Bank Transfer

When you move money from one of your own accounts to another, you could record two separate transactions (a withdrawal on the source and a deposit on the destination) — but that's tedious and error-prone. The Inter-Bank Transfer tab is a single-form shortcut that records both sides in one click, with one shared reference, so the two legs always agree.

Figure 15.1.22 — The empty transfer form: From Account, To Account, Amount, Date, Description, Execute Transfer button, and a Recent Transfers table below.

Figure 15.1.23 — The From Account dropdown open. Only active bank accounts appear — the system prevents you from transferring out of a deactivated account.

Figure 15.1.24 — Transfer of ₹5,000 HDFC → ICICI filled. The From and To dropdowns refuse to select the same account on both sides (you can't transfer to yourself).

Figure 15.1.25 — After Execute Transfer: the form clears and the transfer appears in the Recent Transfers table below. Behind the scenes, one journal entry has been posted (Dr 1020 ICICI ₹5,000 / Cr 1010 HDFC ₹5,000) and two bank transactions have been recorded (one transfer_out on HDFC, one transfer_in on ICICI) linked to the same GL entry.

Tab 4 — Reconciliation

Reconciliation is what you do at the end of every month to prove that what the bank thinks is in your account matches what your books think is in your account. You get a statement from the bank (a PDF or CSV), you look at the closing balance on that statement, and you tell Ragenaizer: "As of this date, HDFC says I have ₹X. Here are all my transactions — tick off the ones that appear on the statement." If the final Difference is zero, you're reconciled. If not, either the bank is wrong, or you missed a transaction, or you have a duplicate — and you need to find it.

Figure 15.1.26 — The Reconciliation tab before starting. Pick a bank, enter the statement's closing balance, pick the statement's end date, click Start Reconciliation.

Figure 15.1.27 — Setup filled: HDFC Current A/C, Statement Balance ₹17,000, Statement Date 30 Apr 2026. ₹17,000 is what we expect the HDFC balance to be after the ₹25,000 deposit, ₹3,000 withdrawal, and ₹5,000 transfer out (25 − 3 − 5 = 17). Click Start Reconciliation.

Figure 15.1.28 — The workspace opens. Left: all unmatched HDFC transactions up to the statement date. Right: a Summary tile showing Statement Balance, Matched Amount (starts at zero), Unmatched Amount, and Difference. Tick the checkboxes on the transactions that appear on the bank statement.

Figure 15.1.29 — After ticking all three transactions and clicking Match Selected, the unmatched list is empty and the Summary tiles update. Now click Complete Reconciliation.

Figure 15.1.30 — The Complete Reconciliation confirm. Like every other confirm in this module, it names the target in full: "Finalise the reconciliation for HDFC Current A/C at HDFC Bank as of 2026-04-30? Statement balance ₹17,000.00, 3 transactions matched. Once completed, this reconciliation is locked and cannot be reopened — any further changes require a new reconciliation."

Figure 15.1.31 — Reconciliation completed and locked. The workspace closes and the form returns to the Start state — ready for next month.

Tab 5 — Import Statement (Excel)

Typing in a month's worth of bank transactions one at a time is a job for an intern — and even then, a boring one. When you have 40+ transactions to enter for the month, the Import Statement tab is the right answer. You download a standard Excel template, paste your real bank statement's debits/credits into it, upload the filled file, preview every row, and post them all in one click.

Click the Import Statement item in the Banking sidebar. On a fresh tenant the page has three things: a Bank Account dropdown (which physical bank this statement belongs to), a Default Counter Account dropdown (the contra side for every imported line — usually a suspense account you'll reclassify later), and a drag-and-drop zone for the Excel file.

Figure 15.1.32 — The empty Import Statement tab. Before uploading anything, click Download Template once (just above the drop zone) to get the reference Excel with three sample rows and an instruction footer. Open it, wipe the sample rows, paste your bank's data into the six columns, save, and come back to upload.

Select the bank and counter account. We'll import into HDFC Current and use Cash in Hand as the counter for this demo.

Figure 15.1.33 — Both dropdowns filled. Both are SearchableDropdown instances — type to filter if you have 50+ GL accounts in your chart. The drop zone becomes active once both are selected.

Click the drop zone (or drag your filled Excel onto it). The file is read client-side with SheetJS — no upload yet. The parser figures out which row is the header by looking for "Date" in the first 5 rows, finds the six columns by their names (not position, so extra columns like Reference are fine), and tries to parse every data row. Three validations run on each row: (1) date parses, (2) description is non-empty, (3) exactly one of Debit or Credit has a value. If any row fails, it's flagged in the preview with a red Error badge and will be skipped on import.

Figure 15.1.34 — Preview of 6 parsed transactions from a demo April 2026 HDFC statement — three credits (customer payments via NEFT/RTGS) and three debits (coffee, electricity bill, salary). Every row has a green OK badge. Below the preview count, a summary says 6 valid · 0 errors. At the top right, Cancel and Confirm Import buttons. Nothing is posted to the GL yet — the file parse is entirely in the browser.

Click Confirm Import. The backend starts an atomic database transaction, loops through every valid row, creates a GL entry per row (Dr Bank / Cr Counter for deposits, Dr Counter / Cr Bank for withdrawals), creates a bank transaction row for each, and updates the bank account balance by the net delta. Either every row succeeds or the entire batch rolls back — you never end up with half a statement imported.

Figure 15.1.35 — The Import Complete summary with Total Rows · Imported · Duplicates Skipped · Errors Skipped. In this run all 6 were fresh and imported. If any errors existed, a table beneath the summary would list them with their 1-indexed row numbers and the specific validation message. Click Import Another to reset the form for the next statement — or switch to the Transactions tab (Banking sidebar) to see the six new rows sitting in the HDFC register, ready to be reconciled next month.

15.2

Expense Management

Tab 1 — Categories

Click Categories in the sidebar. Empty state on day one. Click + Add Category. The modal has three fields: Name (e.g. "Travel"), Description (free text), and Default GL Account (the expense GL account you created in the prep step above — e.g. 5020 Travel). The Default GL Account is what gets debited when the claim is reimbursed; Accounts Payable is credited on approval and Cash/Bank is credited on reimbursement.

Figure 15.2.1 — Categories tab empty state. The empty-state CTA is "No expense categories found" — click Add Category to start.

Figure 15.2.2 — Empty Add Category modal. Three fields; Default GL Account is a searchable dropdown containing every account in your Chart of Accounts.

Figure 15.2.3 — Modal filled in for "Travel" mapped to 5001 Office Rent Expense (in a real tenant you'd have a dedicated 5020 Travel account — we're reusing 5001 for demo brevity). Click Save.

Figure 15.2.4 — After save: one row showing Name, Description, the resolved 5001 — Office Rent Expense GL account label, Active badge, and Edit/Delete row actions. Click Edit to modify, Delete (red) to remove — with a target-named confirmation dialog.

Tab 2 — Policies

Click Policies. This is where you set the rules: "Travel is capped at ₹5,000 per trip and requires a receipt for anything above ₹500." Policies are linked to a Category and are enforced when a claim is submitted — the claim either stays within the limit or generates a warning.

Figure 15.2.5 — Policies tab empty. Click + Add Policy.

Figure 15.2.6 — Policy modal filled: Name "Travel — up to ₹5,000 per trip", Max Amount ₹5,000, Requires Receipt Above ₹500, Category Travel, Active toggle on. Click Save.

Figure 15.2.7 — Policy saved. Row shows Name, Max Amount, Receipt threshold, linked Category, Active badge, and Edit/Delete row actions (both with target-named confirms).

Tab 3 — Expense Claims

Click Expense Claims. This is the business end. A claim has a header (date, description) and one or more line items (category, description, amount, date). You submit a claim; it enters the Submitted state. A different user with approval rights (see the Segregation of Duties note below) approves or rejects it. When approved, a journal entry is posted: Dr Expense / Cr Accounts Payable (to the employee). When reimbursed, another journal entry is posted: Dr Accounts Payable / Cr Cash/Bank.

Figure 15.2.8 — Expense Claims tab. Four stat tiles (Total, Submitted, Approved, Reimbursed), a status filter, a search box, and the Submit Claim button.

Figure 15.2.9 — Submit Expense Claim modal. Header: Claim Date 09 Apr 2026, Description "Chennai client visit — April 3rd to 5th". One line item: Category Travel, Description "Flight MAA — BLR return + airport cab", Amount ₹4,500, Date 03 Apr 2026. Total at the bottom: ₹4,500. Click + Add Item to add more lines if needed. Click Submit.

Figure 15.2.10 — After Submit: a success toast "Expense claim submitted", stats tiles update (Total=1, Submitted=1), and a row appears in the table. Claim number is auto-generated (EXP-2026-00001). Status is Submitted. The row has three action buttons: View, Approve, Reject.

Figure 15.2.11 — Clicking Approve opens a target-named confirm: "Approve EXP-2026-00001 for 'Chennai client visit — April 3rd to 5th' from Abhishek Anand totalling ₹4,500.00? The claim will move to Approved status and become eligible for reimbursement. Nothing posts to the ledger until you reimburse it."

We sign out, sign back in as manager.test@droidsdemo.com, navigate to Accounts → Expenses → Expense Claims, and click Approve on the same row. This time the SoD check passes and the backend posts the first half of the double entry: Dr Travel Expense ₹4,500 / Cr Reimbursement Payable ₹4,500. (Reimbursement Payable is a system fixture account that Ragenaizer auto-creates the first time it's needed — you don't have to set it up by hand.)

Figure 15.2.12 — Approved. The row's status badge flips to Approved, the Submitted tile drops to 0, the Approved tile rises to 1, and the action buttons change: Approve/Reject are gone and a new Reimburse button appears. The expense is now sitting in your P&L and on your balance sheet as a liability to the employee.

Figure 15.2.13 — Clicking Reimburse opens the Reimburse Expense Claim modal: claim summary at the top (number, employee, amount), then a Bank Account searchable dropdown (we pick HDFC Bank — Current A/C, the default), Payment Date, Reference (cheque or UTR number), and Notes. Click Reimburse to post the second half of the double entry.

Figure 15.2.14 — Reimbursed. Status badge is now Reimbursed (green), the Approved tile drops to 0 and the Reimbursed tile rises to 1, and the action column shows just View — the claim is closed. Behind the scenes Ragenaizer just posted Dr Reimbursement Payable ₹4,500 / Cr HDFC Bank ₹4,500, which clears the liability and reduces cash. Flip to Ledger → GL Entries to see both halves of both journal entries chained to this claim.

15.3

Fixed Assets

Tab 1 — Asset Categories

Click Asset Categories. A category is a rule for how a class of assets depreciates: the Name (e.g. "Computers & IT Equipment"), the Depreciation Method (Straight Line, Written Down Value, or Units of Production), the Useful Life in years, and the GL Account + Depreciation Expense Account the postings will hit. Create one category per asset class. Every individual asset you later register will inherit these rules from its category.

Figure 15.3.1 — Asset Categories tab empty. Click + Add Category.

Figure 15.3.2 — Empty Create Asset Category modal. Note there are two GL account pickers: one for the Fixed Asset account (where the purchase cost sits) and one for the Depreciation Expense account (where the monthly depreciation hits).

Figure 15.3.3 — Filled: Computers & IT Equipment, Straight Line method, 3-year useful life, 33.33% rate, both GL accounts picked. Click Save.

Figure 15.3.4 — Saved: success toast "Asset category created", one row in the table.

Tab 2 — Asset Register

Click Asset Register. This is the list of your individual assets — one row per physical thing. Click + Register Asset to add a new one. The modal has: Asset Code (your internal tag like "FA-0001"), Name, Category, Purchase Date, Cost, Residual Value (the estimated salvage at end of life), and Description.

Figure 15.3.5 — Asset Register empty. Stats tiles: Total=0, Active=0, Disposed=0, Book Value=₹0.00. Click Register Asset.

Figure 15.3.6 — Register Asset modal filled for our MacBook Pro 16" M3: code FA-0001, purchase date 01 Apr 2026, cost ₹1,50,000, residual ₹15,000, category Computers & IT Equipment. Click Save.

Figure 15.3.7 — Saved: stats update to Total=1, Active=1, Book Value=₹1,50,000 (no depreciation yet, so book value equals purchase cost). The row has four action buttons: View (eye), Schedule (calendar), Edit (pencil), Dispose (red trash).

Figure 15.3.8 — The View detail modal shows every field including Location and Department (which are optional at create time) and the computed Book Value and Accumulated Depreciation. This is the one place to get a full picture of an asset at a glance.

Figure 15.3.9 — The Schedule button opens a per-asset depreciation schedule showing every month from purchase to end-of-life with the expected monthly depreciation and running book value. Empty on day one because no depreciation has been posted yet — we'll fix that in Tab 3.

Figure 15.3.10 — The Edit modal, pre-filled. Use this to fix a typo in the name, change the purchase date, or adjust the residual value if your estimates change. Changes flow through to the depreciation schedule automatically.

Tab 3 — Depreciation

Click Depreciation. This is where you actually post the monthly depreciation to the GL. You pick a Period End Date (typically the last day of the month you're closing), optionally filter by Asset Category, and click Run Depreciation. The system walks every active asset, calculates its depreciation since the last run up to the period end date, and posts a journal entry: Dr Depreciation Expense / Cr Accumulated Depreciation. Assets whose purchase date is too recent to have accrued a full period of depreciation are skipped.

Figure 15.3.11 — Depreciation tab with no runs yet. Period End Date picker, Category filter, and Run Depreciation button.

Figure 15.3.12 — Clicking Run Depreciation shows a target-named confirm: "Run depreciation for all asset categories up to 30 Apr 2026? This scans N active assets, posts journal entries for each (Dr Depreciation Expense, Cr Accumulated Depreciation), and cannot be undone for this period — you can only reverse by creating correcting journal entries in the General Ledger."

Figure 15.3.13 — After confirming: a success toast and a summary row. If no assets were eligible (e.g. you picked a period that's before any asset's purchase date + one full depreciation period), you'll see "Depreciation run for 0 asset(s)" — that's correct behaviour, not a bug. Pick a later period and try again.

15.4

Subscription Billing

Tab 1 — Billing Plans

Click Billing Plans. A plan is a reusable template — you define it once and then enrol multiple customers into it. The modal has: Name (e.g. "Pro Monthly"), Code (a short identifier like PRO-MO-999), Billing Type (Subscription / Usage / Token / One-Time), Amount (the recurring fee in INR), Billing Cycle (Monthly / Quarterly / Semi-Annual / Annual / One-Time), Status (Active / Inactive), and Description.

Figure 15.4.1 — Billing Plans tab empty state. Click + Add Plan.

Figure 15.4.2 — Create Billing Plan modal filled in for "Pro Monthly" — Subscription type, ₹999/month, Active. Click Save.

Figure 15.4.3 — Plan saved and listed. Row shows Name, Code, Amount, Billing Cycle (Monthly), Status badge, and View / Edit / Delete row actions.

Exercise all three row actions on the Pro Monthly plan to confirm they work end-to-end.

Figure 15.4.3a — The View modal opens read-only with every field of the plan shown for inspection — useful when you want to confirm a plan's details without risking accidental edits. Close to return to the list.

Figure 15.4.3b — The Edit modal opens with every field pre-filled. Adjust the price, change the cycle, flip the status — whatever you change is saved on Update. Existing subscriptions on the plan continue at their original price until you bump them; new subscriptions pick up the new price automatically.

Figure 15.4.3c — The Delete confirm names the target plan in full and warns that active subscriptions on this plan will block deletion. Click Cancel to keep the demo data.

Tab 2 — Subscriptions

Click Subscriptions. This is where you enrol individual customers into a plan. Each subscription links a customer to a plan with a start date, optional end date, and quantity (for per-seat pricing). Subscriptions can be Active, Paused (temporarily stop billing without losing the contract), or Cancelled (end the contract). The Generate Invoices button in the toolbar runs the billing cycle immediately — normally this runs automatically in the background on the 1st of each month.

Figure 15.4.4 — Subscriptions tab on day one. Columns: Customer, Plan, Status, Start Date, Next Billing. Use Create Subscription to enrol a customer (you'll need at least one customer in the Parties module first) and Generate Invoices to manually trigger the billing run.

Figure 15.4.4a — Create Subscription modal with the Customer field expanded. The customer picker is a SearchableDropdown — type to filter, click to select — the same component used everywhere else in the module so the experience is consistent. Plan picker right below it is also a SearchableDropdown.

Figure 15.4.4b — Modal filled: Customer Acme Corp, Plan Pro Monthly, Start Date 01 Apr 2026, Quantity 1. Click Create.

Figure 15.4.4c — Saved. The row appears with Customer, Plan, Active status badge, Start Date, and the computed Next Billing date one cycle later. Click Generate Invoices in the toolbar to run the billing cycle now — that will create a Customer Invoice in the Receivables module which you'll see in Section 10.

Tab 3 — Usage Meters

Click Usage Meters. A usage meter is a counter attached to a customer — think "API calls this month" or "GB of storage". Every time the customer uses the service, your integration posts a usage event to the meter. At billing time, the meter's total is multiplied by the plan's per-unit rate to produce the invoice line. The Record Usage form at the bottom of the page is for manual entry (useful for testing or for metered services you're billing by hand).

Figure 15.4.5 — Usage Meters tab. Create a meter with + Add Meter, then record usage events against it with the Record Usage form below.

Figure 15.4.5a — A meter created for "API Calls" with unit "calls" and rate ₹0.05 per unit. Status Active.

Figure 15.4.5b — The Record Usage form's Meter picker is a SearchableDropdown (it used to be a native select — we converted it for consistency). Type to filter, click to select.

Figure 15.4.5c — 1,250 API calls recorded for Acme Corp on 09 Apr 2026. The event lands in the meter's history table immediately and contributes to the next billing run.

Tab 4 — Tokens

Click Tokens. Tokens are pre-paid credit balances, useful when you want the customer to pay upfront and have their consumption deducted as they go. The page has three sections: Token Management (view current balance for a customer), Purchase Tokens (credit a customer's balance when they pay), and Deduct Tokens (debit their balance when they consume).

Figure 15.4.6 — Tokens tab. Pick a customer (via SearchableDropdown) to see their current balance, then use Purchase or Deduct to adjust it. Every token movement is logged in the audit trail with a reason, so you can always trace what happened.

Figure 15.4.6a — Acme Corp picked from the Token Management customer dropdown. Current balance shows zero (no tokens purchased yet). The Purchase Tokens form to the right takes Customer (same dropdown), Quantity, Amount, and Reference; the Deduct Tokens form mirrors it for consumption events.

15.5

Administration

Tab 1 — Audit Logs

Click Audit Logs. This is the running history of every meaningful action in the tenant: invoices approved, bank accounts created, tax configs updated, periods locked, users logging in — every change leaves a row here with a timestamp, the user who did it, the entity type, the action, and the full before/after payload. It is append-only: nothing can delete or modify an audit log entry, even by a superadmin — that's the point. When an external auditor asks "who approved this invoice?", this page is where you find the answer.

Figure 15.5.1 — Audit Logs tab showing the complete activity history of our demo tenant — every action from COA template initialisation through reconciliation completion is here, with timestamps, user ids, and the full JSON payload of what changed. Use the filters at the top (entity type, user, date range, action) to narrow down. Click View Trail on any row to see the full payload in a modal.

Figure 15.5.1a — The Entity Type filter dropdown open, showing every entity in the tenant: BankAccount, BankTransaction, Customer, ExpenseClaim, FixedAsset, GLEntry, Invoice, JournalEntry, Vendor, and so on. Pick one to scope the log.

Figure 15.5.1b — The same page filtered to BankTransaction entities. Now you see only the bank-transaction lifecycle — create, update, delete — with each row's full payload one click away. This is exactly the kind of slice an external auditor will ask for first.

Tab 2 — Pending Approvals

Click Pending Approvals. Some actions in Ragenaizer require a reviewer's sign-off before they take effect — large payments, sensitive tax config changes, master data edits. When those actions are initiated by a non-approver user, they land here instead of being applied immediately. An admin reviews the list and either approves (the action executes) or rejects (the requester is notified with a reason).

Figure 15.5.2 — Pending Approvals tab showing zero items — nothing waiting. In a production tenant this is where you'd check every morning. Approve and Reject row actions both have target-named confirmation dialogs that spell out what will happen.

Tab 3 — Integrity Check

Click Integrity Check. This runs three automated health checks on your ledger data and tells you PASS/FAIL for each. GL Balance verifies that every posted journal entry has balanced debit and credit totals (this is the fundamental accounting invariant: Dr = Cr). Account Balance Drift verifies that every account's stored balance matches the sum of its posted journal entry lines — if these drift apart, something has gone wrong (usually a failed background job). Period Balance Consistency verifies that fiscal period opening and closing balances reconcile across periods. Click Run Check to execute; in a healthy tenant you want three PASS rows and zero FAIL. If anything fails, the Details column tells you what's wrong and you have a problem to investigate before the next close.

Figure 15.5.3 — Integrity Check results after clicking Run Check. Three PASS rows with human-readable details: Total Debit ₹2,45,000.00 · Total Credit ₹2,45,000.00 · Difference ₹0.00 for the GL balance check, No drifted accounts — all stored balances reconcile with posted JEs for drift, All fiscal period balances consistent for periods. Top-right toast: "All integrity checks passed".

Tab 4 — Job Log

Click Job Log. Ragenaizer runs background jobs for things like the monthly billing cycle, the monthly depreciation run, the overnight integrity check, and the year-end rollover. The Job Log is where you see what ran, when it ran, whether it succeeded, and how long it took. Failed jobs have a Retry button and a View Details action that shows the stack trace and the full job payload.

Figure 15.5.4 — Job Log tab with an All Job Types filter and a Timestamp/Job Type/Status/Duration/Details column layout. Empty on day one in a fresh tenant; fills up as background jobs run on schedule.

Tab 5 — Closing Checklists

Click Closing Checklists. Month-end close is a process, not an event — there's a sequence of things you do in order (post depreciation, reconcile banks, review AR aging, lock the period, etc.). Closing Checklists is where you define that sequence as a reusable template and then track progress through it each month. Check items off as you complete them, generate a signed report when you're done, and lock the period to prevent further changes. You can use the same checklist for every month or customise it.

Figure 15.5.5 — Closing Checklists tab. Filter by Fiscal Year and Create Checklist toolbar buttons, Checklist/Fiscal Year/Status/Progress/Actions columns. Empty in a fresh tenant — create your first checklist for the current month and use it to drive the close.

Figure 15.5.5a — The Create Closing Checklist modal. Pick the Fiscal Year and Period (e.g. April 2026), give the checklist a name, and the system pre-populates the standard month-end task list (Reconcile Banks, Run Depreciation, Review AR/AP Aging, Lock Period, etc.) which you can edit before saving.

Figure 15.5.5b — Saved checklist. Each task is a row with a checkbox; tick them off as you complete the work, and the Progress column on the parent list updates to "X of Y complete". When all tasks are checked the checklist Status flips to Complete and you can lock the period.

Tab 6 — Year-End Closing

Click Year-End Closing. Once a year you close the books for the entire fiscal year. This locks every period, zeros out the revenue and expense accounts by posting their net balance to Current Year Earnings (which rolls up into Retained Earnings for the next year), and creates the new fiscal year ready for postings. You can't undo a year-end close — it's the accounting equivalent of pouring concrete. Before running it, complete every month's closing checklist, run Integrity Check with all PASS, and back up the database.

Figure 15.5.6 — Year-End Closing tab. The big red warning at the top is not decorative: "Close a fiscal year to prevent further modifications. This will lock all periods and carry forward balances. This action cannot be undone." Pick the fiscal year, the pre-flight checks run automatically (same three as Integrity Check, rendered via the same helpers), and if all PASS the Run Closing button unlocks. Confirm to post the closing entries and roll into the next year.

Figure 15.5.6a — The pre-flight panel after picking a fiscal year. The same three integrity checks (GL Balance, Account Balance Drift, Period Balance Consistency) render as PASS/FAIL rows with human-readable details, using the shared formatIntegrityDetails helpers from §15.5.3. The Run Year-End Closing button is disabled until every check is PASS — Ragenaizer will not let you close a year on top of a broken ledger.

Payment gateway setup — per-tenant Razorpay credentials

Ragenaizer's Accounts module can generate payment links, accept gateway webhooks, and auto-apply received payments against open customer invoices — but only if your tenant has its own Razorpay credentials configured. These credentials are stored per tenant, AES-256-GCM encrypted at rest in the same tenant_api_keys table that holds your AI provider keys (OpenAI, Deepgram, etc.), and fetched at runtime by the Accounts service via gRPC. Nothing is ever stored in appsettings.json and keys never cross the REST boundary on read.

To configure them, you need Superadmin access to the Auth service's admin dashboard (this is a separate page from the Accounts dashboard because the keys are stored in the Auth database for security). Open /pages/auth/dashboard.html and click the API Keys tab on the left.

Figure 15.5g — The Auth admin API Keys tab. Each row represents a saved API key with provider / service type / key hint / status / created date. On a fresh tenant the list is empty; here the demo tenant already has Anthropic (LLM), Gladia (STT), and — after the setup below — Razorpay (payment_gateway). The key hint column only shows a short display fragment; raw keys are never returned by the REST API.

Click Add API Key. Select Razorpay (Payment Gateway) from the Provider dropdown. The form changes: the generic single-value API Key input disappears, and three Razorpay-specific fields appear in its place:

Figure 15.5h — The Add API Key modal with Razorpay selected. Three fields: Key ID (the public rzp_test_* or rzp_live_* identifier from the Razorpay dashboard), Key Secret (the server-side secret that matches the Key ID — shown as a password field), and Webhook Secret (optional; only required if you want automatic payment confirmation via Razorpay's webhook callbacks). Service Type is auto-locked to payment_gateway because that's the only meaningful service type for a payment provider.

1. Log into dashboard.razorpay.com and navigate to Settings → API Keys. Click Generate Key (or reveal your existing one). Copy the Key ID and Key Secret.
2. For webhooks: Settings → Webhooks → Add New Webhook. Set the URL to https://accounts.yourdomain.com/api/accounts/bank/webhooks/razorpay/<your-tenant-id>. Razorpay will give you a webhook secret — copy that too.
3. Paste all three values into the Ragenaizer Add API Key form (Key ID, Key Secret, Webhook Secret). Click Save.
4. The Auth service encrypts the three values as a JSON blob with AES-256-GCM and stores them in tenant_api_keys. Raw values are not logged, not returned by the REST GET endpoint, and cached on AccountsService's side for only 5 minutes before being re-fetched.

16.1

What a recurring transaction is (and what it isn't)

Open Accounts → Recurring Transactions from the dashboard Quick Actions grid, or go to /pages/accounts/recurring.html directly. On a fresh tenant you'll see the stats row (Active / Paused / Total Generated) and an empty list. Our tenant already has one running invoice schedule from our earlier SaaS example.

Figure 16.1 — The Recurring Transactions list with one active schedule. Stats show 1 Active · 0 Paused · 1 Total Generated — the "Total Generated" counter is the number of real transactions this schedule has created so far. The Next Run column shows 01 May 2026 because we created the row on Apr 10 and the last run already executed for April.

16.2

Creating a template — Monthly Office Rent

Figure 16.2 — The empty New Recurring Transaction modal. Every field is a searchable dropdown or a native input: Name, Transaction Type (Invoice / Bill / Journal), Frequency (daily / weekly / monthly / quarterly / yearly), Start Date, End Date (optional), the contextual party dropdown (Customer for invoice, Vendor for bill, hidden for journal), Description, Amount, and GL Account.

Fill the form as follows:

• Name: Monthly Office Rent — this is the label that shows in the list; make it human.
• Transaction Type: Vendor Bill — rent is a bill from the landlord, not an invoice you raise.
• Frequency: Monthly.
• Start Date: 01 May 2026 — the first run will happen on this date.
• End Date: 30 Apr 2027 — the lease runs one year; when the schedule's next run would exceed this date the schedule auto-marks itself completed and stops. Leave blank for "run forever".
• Vendor: the landlord (we used CloudKite Hosting as a placeholder in the demo tenant).
• Description: Office premises rent — Whitefield, Bangalore.
• Amount: 85000.
• GL Account: 5310 — Rent. This is the expense account that will be debited on every generated bill.

Figure 16.3 — The filled template. Every schedule has an all-or-nothing validator: if any required field is empty, clicking Create shows a toast "Please fill all required fields" and no request is sent. The backend validates further — end-date must be after start-date, unit-price must be positive, the lines array can't be empty — so bad data never makes it into the database.

Click Create. Toast shows Recurring transaction created, the modal closes, and the new row appears at the top of the table.

Figure 16.4 — Two schedules now running. Stats update to 2 Active. The new Monthly Office Rent row shows Generated = 0 (nothing's been created yet because the first run date is in the future) and Next Run = 01 May 2026.

16.3

How and when schedules run — the 3 AM job and Run Due Now

Figure 16.5 — Clicking Run Due Now opens a confirmation. The message is deliberately specific: "This will process all recurring transactions that are due. Continue?" — not a generic "Are you sure?". Click Process.

Figure 16.6 — After processing: the toast said "Processed 0 recurring transaction(s)" because neither schedule was due (rent starts in May, SaaS next run is already May 1). In a real session where a schedule is due, the generated-count in the list would bump by one and you'd find the new invoice or bill in Draft status on its respective page (Receivables or Payables).

16.4

Pause, resume, cancel — the row actions

Click the Pause (double-bar) button on Monthly Office Rent.

Figure 16.7 — Rent row now shows the yellow paused badge. Stats update: 1 Active · 1 Paused. The 3 AM job will skip every paused schedule — no new bills will be generated for rent until you resume it. The row's action changed from Pause to Resume (▶).

Use Pause when you know in advance that the recurrence needs to stop temporarily (landlord is renovating and has waived one month's rent; the customer is on a pilot extension and won't be billed in August). Use Cancel when the schedule is done forever (the lease ended; the customer churned).

Figure 16.8 — The Cancel confirmation. It's a destructive-style warning (yellow) with a Cancel It primary button because the action is a soft-delete — the row stays in the database with status = 'cancelled' for audit (you can still see the 12 generated bills that came from it via the audit log), but the schedule will never produce another document. Click the grey Cancel at the bottom of the dialog to back out — we won't actually cancel here.

Click Resume to bring rent back online.

Figure 16.9 — Back to 2 Active · 0 Paused. Resume is a pure status flip — it doesn't back-date anything, so any run dates that passed while the schedule was paused are simply missed. If you want to catch up, click Run Due Now afterwards.

17.1

Why bother budgeting inside the books?

Open Accounts → Budgets from the dashboard Quick Actions grid.

Figure 17.1 — The Budgets page with seven rows already populated for FY 2026-27 — three Income accounts (Product Sales, Service Revenue, Subscription Revenue) and four Expense accounts (Cost of Goods Sold, Direct Labour, Salary & Wages, Rent). Stats at the top: 7 Budgets · ₹60,00,000 Total Annual Budget. The Fiscal Year searchable dropdown at the top-left selects which FY's budgets are shown.

17.2

Creating a budget — annual amount + monthly breakdown

Figure 17.2 — The Add Budget modal. Three required fields at the top (GL Account, Annual Amount, Notes), then a Monthly Breakdown grid of twelve inputs labelled Jan through Dec. Above the grid, the Auto-split evenly button divides the annual amount by 12 and populates all twelve cells in one click. The GL Account dropdown only shows Income and Expense accounts that allow direct posting — you cannot budget against headers, Assets, Liabilities, or Equity.

We'll budget Travel & Conveyance (account 5370) at ₹3,60,000/year — ₹30,000/month, assuming roughly one customer-site visit per month. Select the account from the dropdown, type 360000 into Annual Amount, click Auto-split evenly, and add a note.

Figure 17.3 — Filled. Twelve cells now show 30000.00 each. Auto-split evenly handles the remainder automatically — when 1 million is split 12 ways it gives 83,333.33 for 11 months and 83,333.37 on the last month to keep the sum exact. You can always edit any cell by hand after auto-split (for example, if your sales cycle is lumpy and you spend more on travel in Q4).

Click Save.

Figure 17.4 — The new row appears at the bottom of the list. Stats now say 8 Budgets · ₹63,60,000 Total Annual Budget. The Per Month column is a read-only convenience view showing the annual divided by 12 (not the same as the raw m1..m12 values — if you front-loaded Q1, the monthly total is a simple average; the actual per-month values are only visible in Edit mode).

17.3

Budget vs. Actual — the management report

Figure 17.5 — Three summary cards at the top: Total Budget (₹63,60,000), Total Actual (₹7,76,497), and Variance (₹55,83,503 under budget shown in green). Below, sections for Income and Expenses. Each row shows Code · Account · Budget · Actual · Variance · Variance % · Progress bar. Rows with under-consumption (income exceeding target, expense below target) are green; over-consumption is red. The progress bar fills to the utilisation % — it goes yellow above 80% and red above 100%.

Scroll down to see the Expenses section.

Figure 17.6 — Expenses section with all four budgeted accounts. Because no expenses have been booked in FY 2026-27 yet (we created the budgets today), every row shows 100% variance and the progress bars are empty. As real bills and salary runs start hitting the GL, these bars will fill and the Actual column will update in real time — the Budget vs. Actual report reads directly from account_period_balances, the same cached structure the P&L uses, so variance is never stale.

17.4

Copy from prior year — the annual bootstrap

Figure 17.7 — The Copy from Prior Year modal. One required field: Source Fiscal Year. The target is always the fiscal year currently selected in the page toolbar — so you pick the target first from the main dropdown, then open this modal and pick the source. The copy is additive: every existing budget in the target FY stays untouched; only accounts that exist in the source but not yet in the target get a new row. This means you can run Copy multiple times safely — duplicates are de-duped by (fiscal_year_id, account_id) unique key.

Pick the source, click Copy Budgets, and the toast reports how many rows were copied. Then open the list tab — every account in the source year is now budgeted in the target year at exactly the same annual amount and monthly breakdown. Edit the ones that need adjusting and delete the ones that are no longer relevant. Five minutes to bootstrap next year's budget, versus an hour doing it from scratch.