Acumatica Recurring Transactions and Templates

Rent, insurance, retainers, SaaS subscriptions, standing management fees — every finance team has a stack of documents that are identical every month except the date. Acumatica handles these with two distinct mechanisms that people persistently confuse: recurring transactions (the Schedules functionality in GL, AP, and AR) and templates (saved document shapes you copy from manually). They solve adjacent problems, and picking the wrong one creates either unnecessary clicking or unnerving automation. Here is how I decide, and how I set each up.

Recurring schedules: the real automation

The Schedules screens — GL (GL203500), AP (AP203500), AR (AR203500) — take an existing document and re-generate it on a calendar. The flow is the same in all three modules:

1. Create the source document — a journal transaction, AP bill, or AR invoice — but do not release it. A released document cannot be added to a schedule.
2. From the document's Actions, choose Add to Schedule (or build the schedule first and add the document to it).
3. Define the recurrence: start date, frequency (daily/weekly/monthly/by financial period), execution limits — run count or expiry date.
4. Run schedules from Generate Recurring Transactions (or let an Automation Schedule run that processing screen nightly, which is what you actually want).

Each run clones the source document with the new date and leaves the clone on hold or balanced depending on module preferences. That last detail is a policy decision: I generally configure generated AP bills to land on hold so a human approves the monthly rent bill before it hits the ledger — automation should draft, humans should release, at least for the first few cycles until trust is earned.

What schedules handle well, and what they do not

Schedules are excellent when the amount is fixed: rent, retainers, straight-line standing charges. They start creaking when:

• Amounts vary per period. The generated document carries the source's amounts. A utility bill that differs monthly should not be a schedule — that is an import or an AP automation flow.
• Lines change over time. Adding a line to next month's invoice means editing the source document; people forget, and the schedule generates the stale shape forever.
• Proration is needed. Mid-month starts and ends are on you: schedules do not prorate. Generate, then adjust the first and last instances manually.
• You need per-customer variation at scale. Fifty customers on similar-but-different retainers means fifty schedules. It works, but consider whether the contract billing in the Projects module, or a small customization generating invoices from a rate table, models it better. Past a hundred, definitely build it — a simple PXGraph processing screen reading a rate table and inserting ARInvoice records via the SOInvoiceEntry/ARInvoiceEntry graph is a day's work and infinitely more maintainable than a wall of schedules.

Templates: deliberate copies

For everything that recurs irregularly — the quarterly-ish consultancy bill, the journal you post most-but-not-all month-ends — a schedule's calendar is wrong, and what you want is a fast copy. Acumatica gives you two flavours:

• Copy-paste on the document itself. Every document screen's clipboard actions (Copy / Paste from the tool bar) clone the current document into a new one. Zero setup, and honestly underused — teach your AP clerk the copy action and half the "template" requirement evaporates.
• Reversing and auto-reversing entries for GL specifically — an accrual template that books itself out next period via the Auto-Reversing checkbox on the journal, which is the correct tool for month-end accruals rather than a schedule.

Do not use schedules for revenue recognition

A recurring monthly journal moving 1/12 of an annual subscription from deferred to earned revenue works, but Acumatica has a dedicated Deferred Revenue module (deferral codes on AR/AP lines that generate recognition schedules automatically, aligned with the document, handling proration and true-ups). If the recurring entry exists to spread revenue or expense over time, use deferral codes; keep GL schedules for genuinely standalone repeating entries. Your auditors will ask for the deferral schedule report either way, and only one of these produces it.

Monitoring: the part everyone skips

Scheduled generation fails quietly — a closed period, an inactive account on the source doc, an expired schedule someone meant to renew. Two safeguards I install every time:

Tables:   GL.Schedule (and AP/AR equivalents)
Filter:   Active = True
          AND NextRunDate < Today()        -- overdue: should have run
       OR (ExpireDate <> Null
          AND ExpireDate < Today()+30)     -- expiring within 30 days
Columns:  ScheduleID, Description, NextRunDate, LastRunDate,
          RunCounter, ExpireDate

Pin that GI to the controller's dashboard, and pair it with a Business Event that emails when any schedule's next run date slips past due. Ten minutes of setup, and it catches the "rent didn't bill for three months" scenario that otherwise surfaces as an angry landlord.

Wrapping up

Schedules for fixed, calendar-driven documents; copy actions and auto-reversing entries for irregular repeats; deferral codes for anything that is really revenue or expense recognition; and a customization once per-customer variation scales past what a wall of schedules can sanely express. Whichever you choose, make the generated documents land on hold until trust is established, label the source documents loudly, and monitor next-run dates — recurring automation you do not watch is just deferred surprise.