Numerous circumstances exist at least in Australia where if multi dated journal entries were possible a journal entry with dates on each line could be created once instead of annually. Examples include amortizing interest on finance contracts, writing off borrowing costs over five years, claiming blackhole expenditure over five years and special rules for claiming software development pools. Special rules may apply that make it easier to account for it in one journal entry instead of using intangible assets. I would expect future dated journal entry lines to appear in red to be consistent with current future dated entries and debits equaling the credits for each date.
1 Like
And in non-Australian countries too! 
Isn’t that what Recurring Journal Entries does?
2 Likes
In support of your question, I’d say YES.
@Mark, they are not the same. The recurrent journal entry will contain the same financial information, i.e. The transaction data is saved and duplicated each time, with only the transaction dates changing. With the idea being discussed here, there could be different figures or details for the scheduled transactions for each date of the transaction.
I will be adding an illustration later.
Annual interest entered in one journal entry over the full period of a finance contract based on a amortization schedule will show the interest reducing each year with the reduction in the loan principal balance. Instead of retrieving the amortization schedule every year it would be convenient to enter it once and for future years. We can always enter multiple future journal entries but in my view it would appear messy.
There are also certain tax deductions required to be apportioned over several years and the annual deductions are not the same every year, especially in the first year.
Another example is in-house software that must be amortized as follows:
Why not use future dated transactions (eg journal entry, depreciation schedule etc) for such schedules? Readily entered by copy then edit for each date.
A transaction with multiple dates actually has to be converted to these multiple transactions any how to enabling balancing double entry accounting at each date. Doing so automatically for more complex transactions becomes ambiguous.
If it isn’t programmatically too challenging I prefer journal entries with multiple dates but I realize it may be stretching conventional accounting procedures.
Implementing this would open new set of issues. Such as why only journal entries can have multiple dates? Why not other transactions too? I’m sure someone could make a case for Payments or Receipts tabs. Then for other tabs. But where do you draw the line? It would all become very arbitrary.
This would also introduce more inconsistency into user interface because right now every single transaction that can be entered in Manager must have single date. It’s a simple constrain that makes user interface simple. Abandoning these simple constrains would lead to more complicated user interface.
4 Likes
It would not be necessary to change the user interface of the existing transaction forms. This could be a special type of entry named Calendar Entries.
Or Scheduled Transactions
1 Like
Scheduled Transactions is an excellent name!
Or just put a future date in the one of the existing suite of transactions options. Such transactions are already highlighted by showing the date in red.
A report of future dated transactions could be done via custom reports if required.
I’m still not convinced there is really a net benefit of introducing a parallel process for such transactions.
1 Like
Actually my guess is what you would really like is an easy method of showing the full set of related transactions together.
That is actually a common and general problem. The approach I use is to construct the description carefully using the format
- < unique label > < date written so text sort is chronological > < free text >
Then search for the < unique label > and sort by description to display in chronological order.
Use copy / clone for subsequent entries to ensure format consistency.
2 Likes
Or create Drop-down custom field. This could be further leveraged when you want to get custom report for all journal entries where custom field is set to specific value.
I personally would not use unique labels or custom fields to link interest charges for each year covering an entire finance contract. My preference would be to enter the accounting data on one form and the total scheduled interest charges match the total interest from the amortization schedule.
Thinking more about this, the underlying use case is convenient grouping of multi part scheduled transactions.
-
While it is correct almost all multi-part transaction could be done via journal entries (ignoring for a moment the issues with actually implementing a journal with transactions on multiple dates).
-
Doing so is the opposite to Managers design philosophy which is to minimise journal entries in favour of targeted transaction types (payments, receipts, invoices, depreciation schedules, payslips, expense claims etc)
-
Surely there is a reasonable solution which does not drag us all back to just using journal entries.
Having a contract with payments or depreciation on multiple dates is actually common, so any solution ideally should address the majority of applications. For example
- Annual depreciation distributed in equal monthly amounts
- Invoice for 1 year with equal monthly payments.
- Invoices / Contracts with mile stone payments
Edit
Perhaps transactions having a “Schedule” check box which enables entering a series of dates and amounts (or percentage) would be workable. Entering cumulative totals could be used to circumvent rounding problems.
2 Likes
Scheduled transaction process idea.
Step 1.
Create a Scheduled Transaction by entering the Scheduled dates of transactions. The scheduled transaction must have a name.
Step 2.
Next step, Enter financial information and non-financial information on the scheduled transaction form.
Step 3.
If a transaction day arrives, the transaction will post if “Approve transaction before posting” was unchecked.
If “Approve transaction before posting” was checked, the user must be given the following options to complete the transaction (or not).
Finally.
The Schedule Transaction can show a progress report (Status).
To me this sounds like a superset of recurring transactions. I know this idea was glanced over at the beginning of this post but isn’t recurring transactions just scheduled transactions where nothing changes except for the date?
Also, this appears to overlap with this idea as well:
And while I understand this idea a bit more now, but I believe that it could be solved in a simpler way as @Patch have put the problem nicely in those words:
So provided that we have:
- Recurring Transactions
- Multi-Level Authorization
We can then:
- Create a recurring transactions form
- Generate all scheduled transactions in draft state with a single click of a button
- The generate step takes us to a table view with all generated transactions where we can view and edit all transactions individually instead of writing them from scratch.
- Approve each individual transaction in its own time using the exact same mechanism we have right now for recurring transactions (i.e. the yellow banner)
- To access the full schedule again, we can have a special button in the recurring transactions view form which will display a table for all transactions generated using this form.
I think that this is a more compatible with the workflow of Manager, plus it’s faster for entry.
-
Scheduled transaction is a feature consistent with Managers design philosophy to minimises the requirement for journal entries. So while is support scheduled transactions I do not support scheduled journal entries.
-
Schedule display / monitoring and Multilevel authorisation is a separate ideal, of value only after scheduled transactions exist. Scheduled transactions would be valuable without this second enhancement, just as all the other transactions are of value without their recurrent variant.