This is an accounting practice when the company receives an invoice for an expense that covers multiple periods or emits an invoice for a revenue that also covers multiple periods.
The goal is to defer the part of the expense or revenue proportionally over the covered periods.
Proposal
In a new module account_invoice_defer:
On account.configuration we add two deferred account for expense and revenue.
We add on new model account.invoice.deferred with
company
type: Selection [in or out]
journal
invoice line: Many2One to posted account.invoice.line with a domain constraint on the type and a unique constraint
start/end Date
moves: One2Manyto account.move on origin.
state: Selection [draft, running, posted]
When running, it creates and post for each existing standard account.period found (except that one used on the invoice) between start and end date, an account move that credit the deferred account and debit the line account. And for the period used on the invoice it debit the deferred account and credit the line account of the sum of all other moves.
The run state can be executed as long as all the date range is not covered by periods moves.
The ratio between each period is computed based on a daily amount.
A check on Period.close a check is done to ensure that all deferred have been run.
I’m wondering if it’s not better to just post the moves using a wizard (or a cron task) like we do for account_asset. The main reason is because we may have a deferred expense over several years which the fiscalyear is not yet created.
Also it does not make sense to post all the moves if they are not still done.
There are some accounting practices that mean moving credit and debit accounts into diferent accounts on diferent periods. I’m wondering if it makes sense to have a generic solution for both deferred expense/revenue but also for deferring any move line.
I do not think it is really needed for two reasons. First we need to have the periods in order to prepare the moves and know how to compute the ratio. Second such defer is often only for the Y+1 fiscalyear, it should be very rare that it is more and also it is for invoices usually posted close to the end of the fiscalyear.
I will give an example which happen to my company last year:
We purchased some forniture from our offices (on diferent suppliers, so diferent invoices)
As we are a company of recent creation we received a grant from our city counly to pay 50% of the expenses.
In this case we have expenses that are related to several years (due to depreciation), but also a deferred revenue because we the grant is considered as a revenue but should be distributed among all the duration of the asset.
So at the end of the year, we need to create a move which increses our revenue to the proportional part of the income. We do not do for each period (while the result will be exactly the same) because we are deprecating the assets yearly.
Normally the fact of using periods or just for each fiscalyear depends on the size of the company and how they make their statements public. Bigger companies may require to publish its statements each period (or quarter) so they create a move for each period to have a proper statements when published. On the other hand, small companies usually only publish their statements per fiscalyear, so they only create this moves per fiscalyear.
There is another case that can be managed the same way but is not directly realted to expense/revenue. This is about moving liablities from long term to short term. Altought the concept is diferent the resulting moves is very similar: Crediting one account while debiting the other. And the mechanism is exactly the same, you should create a move until the debt is fully paid.
I doubt if the account should be added directly to the configuration or better to the deferred object. IIRC there are diferent types of deferred expenses, so to properly support them we should support having diferent defferred records to diferent accounts.
As you said this is not the same concept at all. It is just a transfer from one account to another, it does not involve “crossing” periods. Neither it needs to be planned in advance as the amount of the liabilities can evolve at any time (ex: early reimbursement)
I checked to chart of account and each time there are only one account used per type to put the expense/revenue out of the income to the balance. This is comprehensive as the goal is just to put off but not to provide any kind of origin.
I agree with Sergi that I find it a better solution to use dates + cron instead of existing periods.
I do not understand why you need the periods. In the case of the assets the user just selects which kind of amortization method they want to use (yearly, monthly). Why is not the same valid here? Even using monthly seems it should apply to every case, or am I missing something?
One example of an expense that needs to be spread into upcoming years is AWS reserved instances, in which you can pay for 3 years in advance:
We also offer similar agreements to our customers.
One example that contradicts the fact that it is for invoices that are close to the end of the fiscalyear is the case for insurances. An insurance (car, building, etc) may be invoiced in any month of the year (not only by the end of the year) and span 1 year.
Because it is not based on dates but periods so to pre-compute we need to know when starts each period.
But as it is not something that is as strictly frame as the asset depreciation. I guess we could use an exact daily amount (and a remainder for the last period). So it will create all the move possible and if there are missing periods, the state goes into running instead of posted and with a wizard to create missing moves and a check when closing a period.
I think this should be considered as an asset. Or even something more complicated as it seems it is a prepayment from which consumption is decreased. So the way it is booked as expense is more complicated.
I’m not sure if daily will be a good value as it will produce a diferent amount depending on the days of the month. Indeed I’ve seen some people doing the calculation with days and other with months. Not sure what is best (probably it depends on the accountant)
The problem is that when you sell such services you can not consider them as an asset, it’s just deferred revenue. Asset is only for expenses.
One example scenario is the rental of assets. A customer could pay 1 year up front to rent/hire a storage container which is actually charged by the month.
Also, it is very likely that the 1 year up front payment will include “consumption” for the next fiscal period.
I think that this is a great generic module. However, in my current model the moves are made by a cron job.