Accrual vs Invoice-based P&L Reporting in Business Central

A scene repeats itself at month-end close across many companies: the controller presents the P&L, the sales director looks at his operational numbers, and both notice something is off. The controller says: “the monthly margin came in at 14%.” The sales director replies: “that can’t be right, what we actually sold in operations was different.” Both are right. They are looking at two versions of the same reality.

The disagreement is not about commercial judgment. It is about date. More specifically, which date the ERP is using to post revenue or expenses to the period being closed. The accounting date does not always coincide with the date of the real economic event.

What the accrual principle actually says

Spain’s General Accounting Plan (PGC) states it in its very first Recognition and Measurement Standard:

“The effects of transactions or economic events shall be recorded when they occur, allocated to the period to which the financial statements refer, including all expenses and revenue that affect that period, regardless of the date of payment or collection.”

This is the same accrual basis principle codified in IFRS (the Conceptual Framework and IFRS 15 on revenue recognition) and US GAAP (ASC 606). Translated: the expense is recognized when the economic event happens, not when it is paid. And not when it is invoiced. When it happens.

In daily practice at mid-sized and large companies, however, what gets posted to a given month are the invoices whose posting date falls inside that month. The posting date is treated, as an operational shortcut, as a reasonable proxy for the accrual date. And usually it is. Except when it isn’t.

Invoice date is not accrual date (even if your ERP treats them the same)

In Microsoft Dynamics 365 Business Central, SAP, Sage and most ERPs on the market, every accounting entry has a single date field. That field serves multiple purposes at once: it is the date reported to tax authorities (SII in Spain, equivalent VAT/sales tax filings elsewhere), it is the date applied to the journal entry, and it is the date used for management reporting.

When the economic event and the invoice happen in the same month, everything lines up. The problem appears when there is a gap. And the gap shows up constantly: subcontractors who invoice the following month, annual-rate utilities billed in January, year-end true-ups, consultancies billing in August for work done in June and July.

In all of those cases, the date the ERP uses to post the expense to a period is not the accrual date. It is the tax filing date. And the two can be weeks or months apart.

This pattern is amplified when the company is under Spain’s SII regime. As we analyzed in this article on how SII distorts the monthly P&L, the 4-day deadline to register invoices makes the gap structural: the posting date can only fall inside the tax window, never outside it.

A numerical example: a professional services firm in May

Picture a mid-sized consultancy. In May 2026 it closes the month and produces two versions of its P&L: one viewed by invoice date (the ERP’s standard operational close) and another viewed by accrual date (the close that would reflect the real economic event).

Item	May (by invoice date)	May (by accrual date)	Difference
Revenue	EUR 180,000	EUR 165,000	-EUR 15,000
Personnel cost	EUR 95,000	EUR 95,000	0
Subcontracted services	EUR 38,000	EUR 22,000	-EUR 16,000
Utilities	EUR 12,000	EUR 12,000	0
Other operating expenses	EUR 8,000	EUR 11,000	+EUR 3,000
EBITDA	EUR 27,000	EUR 25,000	-EUR 2,000
Margin	15.0 %	15.2 %	+0.2 pp

At first glance, the result looks similar: EUR 27,000 vs EUR 25,000 EBITDA, near-identical margins. If the CFO stops at the margin line, May was a normal month.

But the composition is completely different:

• The EUR 15,000 of revenue that shows up in May “by invoice date” is actually work done in March and April invoiced late. The reality is that May only billed EUR 165,000 of services delivered in that month.
• The EUR 16,000 of subcontracted services that show up in May are work delivered in April. The real subcontractor consumption in May was EUR 22,000.
• The EUR 3,000 of other operating expenses that show up in May “by accrual” are a true-up for a utility that was posted late.

May “by invoice date” mixes 3 months of operational activity. Decisions made from that P&L are made on contaminated data.

Four decisions where the difference matters

Beyond the finance committee, there are specific decisions that change sign depending on which version you use:

1. Sales team commissions. If commissions are calculated on revenue invoiced in the month, you reward whoever invoices late. A salesperson who sells the same amount but invoices on the 28th vs the 2nd gets paid differently, without having sold more. If you calculate by accrual date, you reward actual activity.

2. Management bonuses on monthly targets. Same logic. A “good” month may only be good because invoices pending from the prior month got posted in the current one. The bonus is paid on an artificially inflated month.

3. Pricing and operational margins. If you believe a service costs you X when it actually costs Y (because the subcontractor cost was posted to the next month), you set prices on misleading data. Line-level service profitability gets distorted.

4. Early detection of issues. A real activity drop in July is detected “by invoice date” in August, when fewer invoices arrive. “By accrual,” it is detected in July itself, when it happens. Reaction capacity accelerates by a full month.

Why almost nobody does it right (and what works)

Most companies that live with this problem manage it through parallel Excel sheets at close. The controller maintains a spreadsheet with notes like “this expense was really March’s, not May’s.” When the committee meets, the official P&L is presented alongside a verbal caveat: “this is affected by an invoicing gap; May’s real result was X.”

It works. Sort of. And it depends on three things: that the controller remembers every gap, has time at every close to update the Excel, and that the information does not disappear when that person changes jobs or takes vacation.

The professional alternative is structural: add a second date per entry to the ERP. The accounting date stays the official one (SII / tax filing, the one that governs statutory accounting). The analytical date is the actual accrual date (when the service was delivered, when the material shipped, when the economic event occurred). Management reports filter by the analytical date. Statutory and tax reporting keeps using the official one, untouched.

Result: the monthly management P&L reflects the actual operational reality of the month, with no Excels, no manual reconciliation, no two versions of the truth circulating in parallel.

And in Business Central?

Standard Business Central works with a single date per entry (Posting Date). Touching that field affects fiscal period, bank reconciliation and statutory reporting. That is why the solution is not to modify it: it is to add a parallel field for the analytical date that coexists with the original without touching it.

There are industry extensions that do exactly that, keeping the ERP’s core logic intact. The analytical date is available on invoices, credit memos, manual journal entries and inventory movements; it is populated automatically from the receipt or service ticket where one exists; and it feeds Power BI exposing both dates (accounting and analytical) as independent time dimensions.

The questions every CFO asks

Is the accrual principle mandatory in Spain?

Yes. It is set out in the General Accounting Plan (Recognition and Measurement Standard 1) and is mandatory for every company that keeps statutory commercial accounting. The same accrual basis is mandatory under IFRS (used in EU listed companies and most of the world) and US GAAP (ASC 606). What is not mandatory is for each entry’s posting date to exactly match its accrual date. Practice is to use a reasonable approximation, adjusted at year-end when material variances exist.

If my accounting is done properly, shouldn't accrual already be reflected?

At the annual level, yes. Annual statements correctly reflect accrual because year-end adjustments (provisions, prepayments, deferred revenue) are booked. The problem is at the monthly level: few teams have time to make those same adjustments every month, so monthly accounts default to invoice date as a proxy. And that approximation is exactly what distorts management reporting.

What about year-end expenses that get posted in the following year?

At December 31, accruals and deferrals are booked: expense consumed in December but not yet invoiced is provisioned and correctly allocated to the closing year. The annual P&L is clean. But the December month ends up artificially loaded with provisions, and January is artificially light because the real invoices arrive already accrued out. The monthly problem persists even when the annual one is resolved.

Does this only affect companies under SII?

No. SII is the most extreme case (it forces you to register the invoice within 4 days of receipt), but the underlying issue (posting date misaligned with accrual date) affects any company with subcontractor lag, periodic-rate utilities, true-ups or professional services. SII only amplifies it and makes it structurally unavoidable.

In summary

• The accrual principle of the PGC (aligned with IFRS 15 and US GAAP ASC 606) says revenue and expenses are recognized in the period when they occur, not when they are invoiced. But most ERPs only store one date per entry, and the gap with accrual is structural.
• At the annual level, the adjustment is made properly (year-end accruals and deferrals). At the monthly level, it almost never is: the management P&L is contaminated by invoicing gaps.
• In the numerical example of a consultancy, monthly margin was nearly identical (15.0% vs 15.2%) but the composition of the EUR 27,000 EBITDA mixed 3 months of different real activity.
• Four decisions change sign: commissions, bonuses, pricing and early detection of issues.
• The solution that works: two dates per entry. One accounting date (official, tax) and one analytical date (real accrual). Management reports filter by the second one, tax reporting by the first.
• Business Central does not bring this natively, but there are extensions that add it without touching the existing accounting logic.

Want to see how accrual applies to your Business Central?

If you want to see how a second analytical date fits into your Business Central installation, and which management reports change when you start filtering by accrual instead of by invoice date, book a free consultation with a Davisa expert.

Book a free consultation →