Thanks for picking this up Abhishek.
I think we should go with the rolling N-day approach for better flexibility and
control. Backdated transactions are disabled or set to a few days (e.g 7) by
default for control reasons.
Using business date and including manual journal entries is a good approach.
Regards
Anu Omotayo
On Friday, July 10, 2026 at 07:14:23 AM GMT+1, Abhishek Chaudhary
<[email protected]> wrote:
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.
-
Should manual journal entries remain outside the scope of this configuration,
or should accounting transactions also be configurable?
-
Would a single global configuration with an optional tolerance window be
enough, or would separate controls for different transaction types be more
useful?
-
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
