Recurring Transactions

Some transactions repeat on a schedule: monthly rent, weekly payroll, quarterly insurance, annual software renewals. Recurring transactions in Solid let you set up a transaction template once and have Solid produce real journal entries from it on the schedule you specify — automatically or with a "ready to post" prompt.

This is what most accounting products call memorized transactions. The model is the same.

What a recurring transaction is

A template transaction (the same shape as a Check, Bill, Invoice, or Journal Entry) plus a schedule:

Name:                     Office rent
Template:                 Check, $2,400, to "Acme Property Management",
                            DR Rent Expense, CR Operating Checking
Frequency:                monthly
Start date:               2026-01-01
End date:                 (none — open-ended)
Next occurrence:          2026-02-01
Auto-post:                yes

Every time the next occurrence arrives, Solid either auto-posts the entry (if auto_post = 1) or surfaces it in the Recurring Due queue waiting for your approval.

Schedule frequencies

Six frequencies supported:

Month-end handling: a recurring entry that started on the 31st of January advances to the 28th/29th in February (the last day of the month) rather than skipping to March 3rd. The next occurrence after that goes back to the 31st (so March 31, April 30, May 31, etc.).

End conditions

A recurring transaction stops generating new entries based on whichever condition hits first:

• End date — end_date populated; no entries after that
• Remaining occurrences — remaining_occurrences populated; counts down to zero
• Manual deactivation — is_active = 0 stops generation immediately
• Open-ended — both end_date and remaining_occurrences null; runs forever

A 36-month vehicle loan typically uses remaining_occurrences = 36. A monthly rent payment uses neither — runs until you cancel the lease.

Auto-post vs prompt

The auto_post flag chooses between:

• auto_post = 1 — when the next occurrence arrives, Solid posts the entry automatically. The entry shows up in the GL with source = 'recurring'. You see the post in the activity log but don't need to approve it.
• auto_post = 0 — when the next occurrence arrives, the entry sits in the Recurring Due queue. You review and click Post (or edit the amount/date first, then post). Useful for amounts that vary slightly each period (utility bills) or for transactions you want a human in the loop on.

Most users set up a mix: rent and software renewals auto-post; utility bills prompt.

Common patterns

Rent / lease payments

Frequency: monthly
Template: Check, fixed amount, posting to Rent Expense
Auto-post: yes
End: lease expiration date

Software subscriptions

Frequency: monthly or annually
Template: Check or Credit Card, fixed amount, posting to Software & Subscriptions
Auto-post: yes (the amount rarely changes)

Utility bills

Frequency: monthly
Template: Bill (you're invoicing-in from the utility), variable amount
Auto-post: no — utility amounts vary
End: open-ended

Loan payments

Use the Loans module instead of a recurring transaction. Loans handle the principal/interest split correctly per the amortization schedule; a recurring transaction can't.

Recurring invoices to a customer

Frequency: monthly
Template: Invoice to a specific customer, fixed line items
Auto-post: yes (subscription) or no (review-before-send)

After auto-post, the invoice is created in posted status. Email delivery still happens manually — send the PDF through your own email or invoice service.

Quarterly tax estimates

Frequency: quarterly
Template: Check to "United States Treasury", posting to Tax Expense
Auto-post: no — you may want to adjust the amount based on YTD earnings
End: open-ended

Annual software renewals

Frequency: annually
Template: Check, posting to Software & Subscriptions
Auto-post: yes (most annual renewals are predictable)
End: open-ended

Depreciation

Use the Fixed Assets module instead. Fixed assets compute the depreciation amount per the chosen method (straight-line, declining-balance, sum-of-years) and post automatically — a recurring transaction can't do that math.

Generating entries

Solid runs the recurring-generation pass automatically when you open a file (catches up on anything that was due while the file was closed) and again periodically while the file is open. The pass:

1. Selects every active recurring transaction with next_occurrence_date <= today
2. For each: posts (if auto) or queues (if prompt) and advances next_occurrence_date to the following period
3. Decrements remaining_occurrences if set
4. Sets is_active = 0 if either end condition is reached

You can manually trigger generation: Lists → Recurring Transactions → Generate Now. Useful if you've imported historical recurring entries and want to backfill.

Editing a recurring template

Editing a recurring transaction's template affects future-only generation — already-posted entries stay as posted. If you change the amount on a recurring rent from $2,400 to $2,500 because the lease renewed:

1. Edit the recurring transaction's template_data to the new amount
2. Adjust next_occurrence_date if the change is mid-cycle
3. Future occurrences post at the new amount

Past occurrences (already posted at the old amount) are correctly historical — don't edit those unless they're factually wrong.

Pausing without deleting

Don't delete a recurring transaction you might want to resume — the post history references it via recurring_transaction_id and deletion would break the back-pointer. Instead, set is_active = 0. The template stays in the system and can be reactivated later.

Common gotchas

Recurring entry posted on the wrong day. Check next_occurrence_date and the schedule's frequency. Off-by-one errors usually trace to a start_date set in the wrong month or a frequency of monthly when you meant biweekly. Edit the next occurrence date directly to the right one and let the schedule advance from there.

Auto-post failed silently and the entry isn't in the GL. Check the recurring transaction's status — auto-post failures (e.g. an inactive account that the template references) leave is_active = 0 with an error in the audit log. Edit the template, reactivate, and manually generate.

Two recurring entries for the same thing — duplicates. Easy to create when migrating from another product (the import created one, you set up another). Deactivate one of them.

Quarterly recurring is two months later than expected. Quarterly defaults to 3 months from start_date — not your fiscal quarters. If you started in January, occurrences happen in April, July, October, January. To match calendar quarters explicitly, edit each occurrence's date or use four annual recurrences instead.

Annual recurring on Feb 29. Solid advances to Feb 28 in non-leap years (the last day of February), then back to Feb 29 the next leap year. Same pattern as monthly month-end handling.

Cross-references

• General Ledger → transaction types — recurring entries post with source = 'recurring' so reports can filter them
• Loans module — for loan payments specifically (uses amortization, not a recurring template)
• Fixed Assets module — for depreciation (uses computed schedule, not recurring)