I forget the accounting term for this but in other systems I have supported, it was possible to enter a number of periods (n) to automatically split the original amount and spread it over the next n periods.
The client buys and sells maintenance, the maintenance cost or income is not booked in total for the first period, the current practice is to enter a 12 line journal. As they have hundreds of these each month, it is not efficient.
Anyone done this in Nav and willing to set me on the right path?
Ideally, it could be done when the invoice is posted, that would mean the whole amount posted to the G/L Acc with that being automatically reversed into a suspense account and then 12 entries made from the suspense to the G/L Acc using the first day of each period starting with the current period.
I think financials term in English it’s accruals, probably somebody can confirm it.
What you are requesting isn’t quite common mainly in service area. An invoice can cover several months of services orders and it’s desired to split invoice based in number of months of service.
Latest customization that I have done related for a similar process. I will describe how was done.
It was add an option to Sales Invoice to mark it to be handled was an accrual. During Posting an invoice of that type replaced Sales Account by accrual account.
Then was added a report to periodically send % of invoice from accrual account to sales account. It was used a table to maintain amounts posted for each invoice and periods also.
Scenario - create ONE periodic journal for such purposes, which is posted once a month. With every new maintenance agreement, a new line is added to existing ones, setting appropriate End Date.
Shortcomings of such approach:
not all postings are done immediately (but there are companies who do not practice far future postings in G/L, so under question)
you must manually add these new lines (although this can be done thru coding, say, adding a function to Invoice)
Journal bust be cleaned up if End date has come - postings won’t be done, but line remains, and if there are “hundreds of these each month”, it is problematic (but can be bulk deleted by appropriate filtering).
Without droughts that this is the standard ways of archiving this. It’s the way to follow when you have a few invoices to handle.
This biggest drawback is that it’s impractical of archiving in companies with thousands of invoices every week.
As mentioned, this would be very time consuming and difficult to maintain. Also the entries would have be automatic to gain anything useful as well as preventing typing errors.
The sheer volume of entries also makes this impractical I think.
Accruals may be the right term but I always think of them as expected costs that get reversed at the end of the period, that is the reverse of the process i need so not sure but I think there is another term. If it is a cost, it is amortized over a period,
I got this from the web:
amortize
To write off gradually and systematically a given amount of money within a specific number of time periods. For example, an accountant amortizes the cost of a long-term asset by deducting a portion of that cost against income in each period. Likewise, an investor will usually amortize the premium each year on a bond purchased at a price above its principal.
Anyway, it sounds about right.
Your idea seems part the way except I cannot see the need to store the information in a table, if you take the original amount in the ‘accrual’ account, you can filter on the original document number and see the 12 entries, if you then total them up it will come to zero.
A boolean field on the order or invoice line to “amortize” and another, “Number of periods”, then codeunit 80 or 90 as appropriate could be used to generate the entries. An automatic report to show the entries would be useful.
A new field in the G/L Account table to define the ‘offset’ account or "“Amortize Account” would then make the process automatic and under the control of the accounts department. The G/L Account could have the “Amortize” boolean which would then do away with the user entering anything except the number of periods. Come to think of it, you could set it all up in the G/L Account and forget the user, no way it can be missed then.
I will see if there any other suggestions for a few days, thanks for the quick response.
Colin
Decision to use an auxiliary table was based in a few discussions with customer.
We couldn’t ensure that accruals account was changed in setup during period. So we had to know original setup and entry at the time of posting invoice.
Not all invoices were divided in same way, so in that table all the lines were already split by G/L accounts and posting dates. When the report from accruals is run it posts a GL Journal line for each line in that particular period.
You way are also correct but we have taken an different approach.
When raising invoice (sales ) use a Resource; Resource Posting Groups points to balance sheet account; deferred revenue. After invoice posted create / add to recurring journal (total amount divided by number of months of contract, P&L account, Dimensions and Expiry Date). Post recurring journal to release revenu from Balance Sheet to P&L.
Use similar process for Purchasing (use G/L Account not Resource).
It’s a manual process with manual controls. That’s the job of the accounts department.
You could make automate the above process but the cost could be high and the value low.
Alternative is to contact NAV Partner in Sweden (softronic) who have an add-in for managing contract revenues.
For Version 5 we will use the manual process of recurring journals (manging thousands of contracts).
It wasn’t that complicated to customize, it was really quite simple. A couple of days was enough.
There is many standard ways of achieving it but all manually, but in this case didn’t to do it manually.