Accounting rules and frequent postings in Apache Fineract: how journal entries are really made

If you have gone looking for "accounting rules," "frequent postings," or a "journal entry template" in Fineract, you have probably ended up more confused than when you started. The setup instructions live in the administrator manual, the posting screen lives in the operational manual, there is a page titled "Advanced Accounting Rules" that has nothing to do with accounting rules, the word "frequent" sounds like it means "recurring" and does not, and "journal entry template" turns out not to be a real thing at all. We run managed Fineract and set this up for institutions, so here is the whole picture in one place, accurately, with the names untangled.

Three ways a journal entry gets created

Start here, because almost all the confusion comes from not knowing which of these you are looking at. Every line in Fineract's general ledger lands in the same place, the acc_gl_journal_entry table, but it can get there three different ways.

The first is automatic. When a loan is disbursed or a repayment posts, Fineract creates the journal entries itself, based on the general-ledger accounts you mapped on the loan or savings product. You configure the mapping once per product; after that, every transaction posts its own entries with no human involved. This is the bulk of your ledger, and it is the part most people mean when they say "Fineract does the accounting."

The second is a frequent posting. This is a manual journal entry that a member of staff posts by hand, but with the accounts pre-chosen for them by an accounting rule, so they cannot pick the wrong ones.

The third is a free-form manual entry. Someone with the right permission opens the journal entry screen and selects any general-ledger accounts directly, debit and credit, with nothing constraining the choice.

The first is automatic; the second and third are manual, and you can list just those with the manualEntriesOnly filter on the journal entries API. Accounting rules and frequent postings are entirely about that second path. Keep that straight and the rest falls into place.

What an accounting rule actually is

An accounting rule is a saved debit-and-credit account mapping. Nothing more. Fineract's own code describes the motivation bluntly: in a microfinance institution, non-accountants post journal entries all the time, so the rule is "an abstraction on top of manual journal entries for enabling simpler data entry." You define, once, that a particular kind of posting always debits these accounts and credits those, and from then on staff select the rule and fill in an amount instead of choosing accounts.

A rule comes in three shapes. The simplest fixes both sides: debit this one account, credit that one. The second pins one side and offers a list for the other, using account tags, so the rule says "debit one of these expense accounts, credit cash." The third is compound: multiple debits, multiple credits, or both, drawn from the allowed accounts. A rule can also be scoped to a single office, so a branch only sees the rules that apply to it.

In the database this is the acc_accounting_rule table, with the allowed-account lists in acc_rule_tags. Over the API it is /accountingrules, with a companion /accountingrules/template endpoint that hands the UI the accounts, offices, and tags it needs to draw the form. Our accounting rules guide has the exact request bodies; the point here is the shape of the thing, not the JSON.

One real prerequisite catches people out: the list-and-compound rules need account tags, and tags are not where you would expect. You create them under system code values, then attach them to individual accounts in the chart of accounts, and only then can a rule reference them. It is a three-screen setup the docs never draw as one flow.

Frequent postings: a screen, not an endpoint

Here is the thing that surprises everyone who goes digging: there is no frequent-postings API, and no frequent-postings table. Search the Fineract source for it and you find nothing. "Frequent Postings" is purely a label on a menu in the web UI.

What the screen does is apply an accounting rule. You pick a rule, an amount, a date, and an office; if the rule offers a list or allows multiple lines, you choose which specific accounts; and the UI posts a normal journal entry through the ordinary /journalentries endpoint, passing along the rule's id. Fineract then resolves the rule, checks that the accounts you chose are actually allowed by it, and writes the debit and credit legs. A frequent posting is just a manual journal entry with guard rails, and the guard rails are the rule.

So when you search for /frequentpostings and come up empty, that is correct. The real endpoint is /journalentries, and the rule is what makes it a "frequent posting" rather than a free-form one.

"Frequent" does not mean "recurring"

This is the single most common wrong assumption, and it is worth stating flatly: frequent postings do not post themselves on a schedule. The name means "a journal entry you post often," not "a journal entry Fineract repeats for you." There is no cron, no recurrence setting, nothing that fires monthly rent or payroll on its own.

It is a reasonable thing to want, and the community wanted it too. There is an old proposal for genuinely recurring journal entries, with recurrence dates and a daily job to trigger them, going back to 2016. It was never built. The ticket was closed without shipping, and nothing has replaced it since. If you need a journal entry to post automatically every month, the answer today is to script it yourself: call the journal entries API from your own scheduler. Fineract will not do the recurring part for you, no matter how much the word "frequent" implies otherwise.

The "Advanced Accounting Rules" trap

Now the name collision that sends the most people down the wrong path. In the Mifos manual there is a page titled "Advanced Accounting Rules." It is not about accounting rules. It is about product-level general-ledger mapping: the screen where you tell a loan or savings product which accounts its fund source, fees, penalties, and the rest should post to. That is the automatic path from the first section, configured per product.

So you have two features with almost the same name doing opposite things. Plain "accounting rules" are standalone, manual, and feed frequent postings. "Advanced accounting rules," despite the name, are part of a product's configuration and drive automatic postings. If you are trying to change how a loan's disbursement posts to the ledger, you want the product's accounting configuration, not the accounting-rules screen, and the charge-off accounting post walks through that automatic side for one event.

And "journal entry template" is not a thing

People search for a "journal entry template" or journalentrytemplate expecting a database object or an endpoint. There isn't one. There is no /journalentries/template, and no table by that name.

The phrase gets used two ways, and both have a real answer. Sometimes people mean the accounting rule itself, which our documentation does describe as a reusable journal-entry template, because that is exactly what it is. Other times they mean the reference data a client needs to draw the posting form, the list of accounts and payment types and so on, and that comes from the chart-of-accounts template endpoint, not a journal-entry one. One thing it is not: there is a /journalentries/downloadtemplate, but that hands you an Excel workbook for bulk import, which is a different job entirely.

A worked example: payroll

Put it together with the example the Mifos docs set up but never finish posting. You run payroll monthly and want a clerk to post it without touching the chart of accounts.

First, the tags. You create an expense tag, "Payroll," and attach it to each expense account a payroll run can hit: salaries, employer tax, benefits. You create an asset tag, "Cash," and attach it to the bank accounts payroll can be paid from. Then you build the rule: name it, scope it to an office if you want, set the debit side to the payroll expense tag and the credit side to the cash tag, and allow multiple debit lines so one run can split across salaries and tax.

From then on the clerk opens Frequent Postings, picks the payroll rule, enters the amounts against each expense account and the bank account, and submits. Fineract writes a single compound journal entry, debits and credits balanced, against the accounts the rule allowed and no others. The clerk never sees the full chart of accounts, and cannot post payroll to the wrong place.

The gotchas worth knowing

A few things bite people, and most of them are Fineract behaving correctly:

• Backdated entries get rejected near a period close. If you try to post or reverse a journal entry dated before a branch's accounting closure date, Fineract refuses it. This reads like a bug and is not one; ledger closures are a hard guard, on purpose.
• Reversing a reversal goes wrong. When you reverse a journal entry, the reversal is itself an entry, and the UI will happily offer to reverse that too. Do not; reversing a reversal produces an entry that does not mean what you think. Reverse the original, once.
• A reversal must mirror the original exactly. Whatever accounts an entry hit on the way in, the reversal has to hit the same ones. Most "my trial balance is off after a reversal" reports trace back to this.
• The office dimension is real. Rules can be office-scoped and entries carry an office, so a rule created for one branch will not appear for another. Money moving between offices is its own accounting exercise, not a single rule you reuse.
• Only some accounts can take a manual entry. A journal entry, frequent or free-form, can only post to a detail account that has manual entries enabled, and the user needs the create-journal-entry permission. Header accounts and locked-down accounts are not options.

So, what should you do?

Accounting rules and frequent postings are a small, sharp feature: they let non-accountants post recurring kinds of journal entries quickly and safely, by saving the account mapping once. They are not the automatic product accounting, they are not scheduled, and they are not the confusingly-named product mapping. Set up your chart of accounts, map your products for the automatic entries, and build a handful of accounting rules for the manual postings your team makes often. The full configuration is in our accounting rules guide and the accounting setup guide.

That is the part we take off your plate. Finecko runs managed Apache Fineract with the chart of accounts, the product mappings, and the accounting rules set up correctly, so the journal entries post where your controller expects and the ledger ties. If you would rather run it yourself, the map above is the one the official docs never quite draw: three ways an entry is born, one of which is the rule-driven frequent posting, and none of which is the recurring schedule the name keeps promising.