The design sounds good to me. In accounting systems it is common to disallow backdated transactions for "Reconciled" transactions, or require an over-ride authorization. That is, until the monthly, or sometimes as much as daily reconciliation process has occurred, then transactions can be backdated. I would argue that manually entered transactions should also follow this same ruleset in the journal. The tolerance could be a global "last month"... which is to say not 30 days or 60 days but the last calendar month. And yes, use the business date.
Thats my 2 cents. On Thu, Jul 9, 2026 at 10:12 PM Abhishek Chaudhary < [email protected]> wrote: > Hi all, > > I'd like to help move FINERACT-1950 ( > https://issues.apache.org/jira/browse/FINERACT-1950), "Disallow backdated > transactions - A Global Configuration", forward again, if the community is > still interested. > > The ticket was filed by Ibrahim Kimbugwe in 2023 and received good support > from the community. Bharath Gowda mentioned that it solves a practical > operational issue, especially around month-end and year-end processing. > Ibrahim and Francis Guchie had also built and tested an implementation > using a global configuration along with a permission-based override, > allowing authorised users to post backdated transactions when required. I > think that's a good approach since it fits the common teller and accountant > workflow. It looks like the implementation was never merged upstream, and > the ticket is currently unassigned. > > Ibrahim, Francis, if you still have the implementation and are willing to > share it, I'd be happy to help get it upstream. If the code is no longer > available, I'd like to pick up the ticket and continue with the same > approach. > > One thing that has changed since then is that the Business Date and COB > functionality has matured quite a bit. Because of that, I think it would > make sense to base the validation on the current business date rather than > the system date. > > My initial idea is something along these lines: > > - > > Introduce a new global configuration, for example > disallow-backdated-transactions, disabled by default and following the > existing GlobalConfigurationProperty pattern. > - > > Allow the configuration value to optionally specify a tolerance of *N* > days, similar to the existing *-for-days* style configurations. > - > > When enabled, reject client-facing portfolio transactions such as > savings deposits, withdrawals and loan repayments if they are dated before > the current business date. > - > > Keep a permission-based override so authorised users can still perform > backdated transactions when necessary. > - > > Leave manual journal entries unaffected, as discussed in the original > ticket. > - > > Add integration tests covering the enabled and disabled cases, the > tolerance window and the permission override. > > For context, I noticed that > allow-backdated-transaction-before-interest-posting and > backdate-penalties-enabled already exist, but both address more specific > cases rather than backdated transactions in general. > > I'd appreciate some thoughts on a few points before I start working on it. > > 1. > > Should manual journal entries remain outside the scope of this > configuration, or should accounting transactions also be configurable? > 2. > > Would a single global configuration with an optional tolerance window > be enough, or would separate controls for different transaction types be > more useful? > 3. > > For the override, would a dedicated permission be the preferred > approach, or should it integrate with the existing maker-checker flow? > > If this direction sounds reasonable, I'll post a short design note on the > JIRA ticket and follow up with a PR. > > Regards, > > *Abhishek Chaudhary* >
