Retroactivity

What is retroactivity in Fincome?

Fincome does not store your figures once and for all: it continuously recalculates your MRR, your ARR, and your revenue from your billing data. If a source data point concerning a past period changes, the figure for that past period changes too.

Concretely: you reported €100,000 of MRR for March to your board. In June, a March invoice becomes unpaid. Depending on your configuration, March MRR may be recalculated to €98,000. The figure was not wrong — the billing reality is what changed.

In Fincome, retroactivity does not behave the same way depending on which data you are looking at. Two scopes therefore need to be distinguished.

Scope	What can be retroactive
MRR / ARR and KPIs (Analytics)	Invoice status changes (unpaid, void) and credit notes
Revenue recognition (Rev Rec)	Credit notes, and voided invoices. An unpaid invoice, however, has no effect

Both scopes are controlled in the same place: Settings (gear icon) > Calculation options.

1. Retroactivity on MRR/ARR (Analytics)

Two calculation options determine how far retroactivity reaches in your analyses.

a. Invoice statuses counted

The option "Invoice statuses counted in the MRR-ARR and KPI calculation" defines which invoices contribute to your MRR. This is the first source of retroactivity, because an invoice changes status over time: it is issued (open), then paid… or reclassified as unpaid by your billing tool once the due date has passed.

If an invoice's status falls outside the selected scope, the invoice stops contributing to MRR — including for months that have already elapsed and that it covered.

Concrete example. A customer is billed €1,200 for an annual subscription starting 1 March, i.e. €100 of MRR per month. Your option is set to the default choice, "Only open and paid invoices".

In March, the invoice is open: it is within scope. March MRR does include the €100.
In June, the invoice still has not been paid and your billing tool switches it to unpaid.
The unpaid status is not within the selected scope. Fincome therefore removes this invoice from the calculation for every month it covered: March, April, and May MRR each drop by €100.

The behaviour depends directly on your choice:

Only open and paid invoices (default): an invoice going from open to unpaid leaves the scope → retroactive drop on the months concerned.
Only paid invoices: the most conservative scope, but retroactivity also works the other way — an invoice paid late retroactively increases the MRR of the months it covers, at the moment it is collected.
All invoices regardless of their status (incl. unpaid): status changes no longer have any effect on MRR. This is the most stable setting over time, at the cost of an MRR that includes revenue you may never collect.

Good to know: there is no universally "right" setting. The principle is to choose the one that reflects how you read your business, then leave it alone — every change recalculates your metrics across the entire platform.

b. Credit notes

The option "Include credit notes" determines whether credit notes are deducted from MRR, and above all on which period they are deducted. Three choices:

Account for credit notes: the credit note is allocated to the period of the original invoice → retroactive effect on past months.
Account for credit notes non-retroactively: the credit note is allocated to its own issue date → past months remain untouched.
Do not account for credit notes (default): credit notes do not enter the MRR calculation.

Concrete example. A customer is billed €1,200 in January for 12 months (€100 of MRR/month). In June, you issue a €600 credit note as a goodwill gesture.

With "Account for credit notes": the credit note is attached to the January invoice. The subscription's MRR is recalculated to €50/month from January onwards. The five months already closed drop.
With "Account for credit notes non-retroactively": January to May stay at €100, and the deduction applies from June onwards.

2. Retroactivity on revenue recognition (Rev Rec)

On the revenue recognition side, the logic is different — and this is a frequent source of confusion: not all status changes are equal.

An invoice going to unpaid has no impact on recognised revenue. It remains counted by default, because the service was indeed delivered: revenue recognition follows the reality of the service, not that of collection.
An invoice going to void (cancelled), however, leaves recognised revenue, just as it leaves MRR. The invoice no longer exists: there is nothing left to recognise.

This is the distinction to remember: on the Rev Rec side, an unpaid invoice changes nothing, a void changes everything.

The only retroactivity you can control through an option concerns credit notes, via "Non-retroactive revenue recognition of credit notes":

Disabled (default): the credit note is spread over the service period of the original invoice → recognised revenue for months already closed is corrected.
Enabled: the credit note is recognised from its issue date onwards → closed months no longer move.

Concrete example. A €1,200 invoice in January for a service covering January to December, i.e. €100 of recognised revenue per month. A €600 credit note issued in June.

Option disabled: the €600 is re-spread over January–December. Every month, January included, drops to €50 of recognised revenue.
Option enabled: January to May stay at €100, and the €600 is recognised from June onwards.

If you produce a monthly accounting report that you do not want to move after closing, this is the option to enable.

To understand why these two scopes do not react the same way, see Difference between MRR and revenue recognition.

Which event moves what?

This table helps you quickly identify the likely cause when a past figure has changed.

Event	MRR / ARR	Recognised revenue
Invoice switching to unpaid	Retroactive drop, depending on the status scope selected	No impact
Invoice switching to void (cancelled)	Retroactive drop	Retroactive drop
Credit note issued on a past invoice	Depends on the "Include credit notes" option	Depends on the "Non-retroactive revenue recognition" option
Modified invoice (amount, lines, service date)	Recalculation of the periods concerned	Recalculation of the periods concerned
Invoice issued on a past date	Retroactive increase	Retroactive increase

What retroactivity cannot prevent

The options above govern the retroactivity tied to calculation rules. They can do nothing about the retroactivity that comes from the source data itself: as soon as an invoice attached to a past period is created, modified, or cancelled, Fincome accounts for it, and the figures for that period change. Three cases are common and unavoidable.

1. A deleted invoice becomes "void"
An invoice deleted in your billing tool is not erased: it comes back into Fincome with the void (cancelled) status. It therefore leaves the calculation, and the periods it covered are recalculated downwards — on MRR as well as on recognised revenue. This is the only status change that affects both scopes at once.

2. An invoice or an invoice line is modified
Whether the change is made manually in Fincome or arrives through the sync with your billing tool, it triggers a recalculation of the periods concerned. The most common cases:

the invoice status changes;
the service date (billing period) is modified, or filled in when it was previously missing;
the amount changes, or invoice lines are added.

A service date appearing on an invoice that previously had no period is a particularly visible case: the invoice moves from an approximate attachment to a precise one, and MRR is redistributed across the months actually covered.

3. A new invoice is generated on a past date
An invoice issued today but whose service period started three months ago (billing catch-up, an adjustment, a contract signed with retroactive effect) adds MRR to months that are already closed.

Good to know: these recalculations are not anomalies. Fincome remains the mirror of your billing — if your billing changes, your analyses change. To keep a snapshot of a closed month, the good practice is to export it at closing time (see Data exports from Fincome).

Best practices

Settle your options during data scoping, not every month. Every change recalculates the full history and makes comparisons between reports difficult.
For an MRR that is stable over time: set the statuses to "All invoices regardless of their status" and credit notes to non-retroactive.
For a report faithful to collection: keep the default scope, and accept that past months will move as unpaid invoices appear.
Export your data at every close to keep a frozen record of what was communicated: there is no period locking in Fincome.
Check manual edits before concluding there is a bug: they also apply retroactively (see Manual edits in Fincome).

FAQ

My March MRR dropped even though I changed nothing. Why?
In the vast majority of cases, a March invoice changed status (switching to unpaid or void), or a retroactive credit note was issued. Use the underlying view on the month concerned to identify the invoice responsible.

Why does my MRR move but not my recognised revenue?
That is the signature of an unpaid invoice. An invoice switching to unpaid leaves the MRR calculation (depending on your status scope) but remains counted in recognised revenue, since the service was delivered. If both scopes move, look instead for an invoice switched to void, a credit note, or a modified invoice.

Can retroactivity be disabled entirely?
No. The calculation options let you neutralise the retroactivity tied to invoice statuses and credit notes, but not the retroactivity that comes from a change in the source data (an invoice deleted, modified, or issued on a past date).

How do I freeze a closed month?
There is no period locking in Fincome. The method is to export the month's data at closing time, and to enable the non-retroactive options if reporting stability is your priority.

If I change a calculation option, should I expect all my figures to move?
Yes, and that is normal. Any option change recalculates your metrics across the entire platform (Reporting, Forecast, Benchmark) and across your full history.

Updated on: 07/09/2026

Was this article helpful?

Thank you!