Skip to main content
Some accounting work happens on a fixed rhythm: a monthly rent expense, a quarterly retainer invoice, a depreciation journal every month-end. A recurring transaction is a schedule that generates these documents for you automatically. You define what to create (an expense, an invoice or a journal entry) and how often, and Hitaji 360 produces the real document each time the schedule comes due — keeping a full history of every occurrence. You’ll find this at: /accounting/recurring
📷 Screenshot: Recurring Transactions page with stats cards, status tabs and the “New Recurring” button — to be added.

​
What a recurring transaction can generate

A recurring transaction targets exactly one entity type: Each generated document is a normal expense / invoice / journal entry and behaves exactly like one you created by hand from that point on.

​
Access (multi-business note)

The Recurring Transactions area is available to users with accounting read access (accounting:read) in the active business. Recurring transactions are scoped to the accounting book of the business that is active when you create them; switching business switches which schedules you see.

​
The lifecycle of a schedule

Every recurring transaction has a status: The page header shows count cards for Total, Active, Paused and Completed, and status tabs to filter the list. You can also filter by entity type (Expense / Invoice / Journal Entry) and search by name.

​
Creating a recurring transaction

  1. Go to /accounting/recurring and click New Recurring.
  2. Fill in the schedule header:
  3. Fill in the Template Data — the details of the document to generate. The fields depend on the type you chose: Expense
    • Vendor (contact), Amount (required), Category, Description (required), Currency, and Notes.
    Invoice
    • Customer (required), Due Days (how many days after generation the invoice is due), and one or more Line Items — each with a description, quantity and unit price. Optional Terms and Notes. The form shows a running estimated total.
    Journal Entry
    • Memo (required) and at least two Lines, each with an account and a debit or credit amount. A running Dr/Cr total is shown. (Remember a journal entry must balance — see Journal Entries.)
  4. Click Create Recurring. The schedule starts Active, and its first next occurrence is calculated from the start date and frequency.
📷 Screenshot: New Recurring Transaction modal with the Journal Entry template fields expanded — to be added.

​
How and when documents get generated

A background scheduler runs every 5 minutes. On each run it looks for schedules that are due (active, with a next occurrence at or before now) and generates the next document for each. You don’t have to do anything for this to happen. For each successful generation the system:
  • creates the target document (and, for a journal entry, posts it);
  • advances the schedule’s next occurrence by the frequency;
  • increments the occurrence count and stamps last generated;
  • writes a history record of the occurrence.
Generation is protected against duplicates: even if two scheduler runs (or a manual generate and the scheduler) collide, exactly one of them produces the document for a given slot — you won’t get double invoices for the same cycle. If a particular generation fails (for example a referenced account is missing), the schedule still moves on to its next slot and the failure is recorded in the history as FAILED, so an operator can see and fix it. The system does not silently retry the same slot.

​
Generate now (manually)

To run a cycle immediately rather than waiting for the scheduler, use Generate now (the bolt icon) on an Active schedule. This produces the next document on demand. It refuses to run if the schedule is completed or cancelled, if the maximum occurrences has already been reached, or if the end date has passed.

​
Managing a schedule

Row actions (and the same actions on the detail page) let you control a schedule: Click a row to open the schedule’s detail page, which shows its settings and the full occurrence history (each generated document, when it was generated, the slot it filled, the amount, and whether it succeeded or failed).
📷 Screenshot: Recurring transaction detail page showing the occurrence history table — to be added.

​
When a schedule finishes

If you set a maximum occurrences, the schedule automatically becomes Completed on the generation that reaches the cap, and its next occurrence is cleared so it never runs again. If you set an end date, generation simply stops once that date has passed.

​
Behind the scenes

  • Expense and Invoice schedules create a draft/open document of that type, which then follows its own normal posting and payment flow.
  • Journal Entry schedules create and post the entry in one move, so the ledger is updated immediately. The entry must balance — if the template lines don’t, that occurrence is recorded as failed.
For the double-entry mechanics of generated journal entries (debits, credits, balancing, reversal), see Journal Entries.

​
Known gaps / things to verify

These are noted for the team and should be confirmed before this page is considered final for end users:
  • Detail-link route mismatch. From the list, clicking a row navigates to /accounting/recurring-transactions/:id, but the registered route for the detail page is /accounting/recurring/:id. The row click may land on a not-found page. The list and detail pages otherwise live under /accounting/recurring.
  • Expense template — account fields appear ignored. The “New Recurring” form collects an Expense Account and a Payment Account for expense schedules, but the back-end expense generator only uses amount, description, category, contact, currency and notes — it does not appear to pass those two account selections through. Confirm whether these fields actually influence the generated expense before documenting them as effective.
  • No dedicated RBAC slug. Creating/pausing/cancelling/generating recurring transactions is gated only by general accounting workspace access (accounting:read on the route), not by a finer-grained permission. Confirm this is intended.