Thanks for the feedback! I agree that using the business date is the right approach, and your point about including manual journal entries makes sense as well. I'll take both into account while refining the design.
I also like the idea of aligning the tolerance with calendar months rather than a rolling N-day window. One thing I'm still thinking through is whether the allowed window should cover the current and previous calendar month, or only the current month. My initial thought is that current plus previous would be the safer default for organisations that reconcile in the first few days of the following month, but I'd be interested to hear what others think. I'll capture the full proposal on FINERACT-1950 before starting the implementation. Regards, Abhishek Chaudhary On Fri, 10 Jul 2026 at 11:01, James Dailey <[email protected]> wrote: > 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* >> >
