Why does an invoice's received date differ from its invoice date, and why does that matter for AP aging?

The invoice date is whatever date the vendor printed on the document; the received date is when it actually arrived in your system. Microsoft's Dynamics 365 docs list these as genuinely separate fields alongside posting date and due date — a stale invoice arriving weeks late has an invoice date predating when your team could have acted, which skews aging if the wrong field drives it.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 14, 2026Last reviewed September 14, 2026Editorial policy

Part of the accounts payable and invoice processing guide.

Invoice date	Whatever date the vendor put on the document — blank by default in some systems until manually entered
Invoice received date	The date it actually entered your system — defaults to the current date
Posting date	A third, separate field — also defaults to current date, drives the accounting period
Due date	Calculated from posting date (or invoice date, if set) plus payment terms
AP aging implication	Which of these fields drives your aging report changes whether a late-arriving invoice looks old or new

These are genuinely separate fields, not duplicates

Microsoft's own Dynamics 365 documentation on vendor invoice dates lists four distinct fields on a pending vendor invoice: invoice received date, invoice date, posting date, and due date. By default, the system sets invoice received date and posting date to the current date automatically, while invoice date is blank until someone enters it — and when it is entered, the system recalculates the due date based on that invoice date and the payment terms instead of the posting date. These aren't redundant labels for the same concept; each drives different downstream calculations.

Why the gap between them opens up

A vendor dates an invoice the day they generate it. It might not reach AP — by mail, by a slow internal forwarding chain, or because it sat in an inbox — for days or weeks after that. The invoice date reflects the vendor's timeline; the received date reflects yours. A three-week-old invoice date on something that landed in the system yesterday isn't a data error, it's the normal consequence of however long the document took to actually arrive.

Why this matters for aging specifically

AP aging reports bucket outstanding bills by how long they've been open — but "open since when" depends on which date field the report uses. NetSuite's own accounting preferences explicitly let a user choose to age bills and invoices by due date or transaction date, which is exactly this choice made configurable. Age by invoice date, and a late-arriving invoice can show up already deep in an aging bucket the moment it's entered, even though your team just received it and hasn't had a realistic chance to process it. Age by received or posting date instead, and the aging reflects how long it's actually been in your hands.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Field mapping

Four dates on one vendor invoice, and what each one drives

Field	Default	What it drives
Invoice received date	Current date	When your team actually got it
Invoice date	Blank until entered	Recalculates due date and cash-discount date when set
Posting date	Current date	Which accounting period the transaction lands in
Due date	Calculated	Based on posting date or invoice date, plus payment terms

Frequently Asked Questions

There's no universal right answer — aging by invoice date reflects the vendor's timeline and is more relevant for cash-discount and due-date calculations; aging by received or posting date reflects your team's actual processing timeline. Most systems make this configurable specifically because different organizations reasonably prioritize different answers.

Some systems specifically validate against this — Dynamics 365, for instance, can be configured to require the invoice date field and to error if the invoice date is later than the posting date, since a future-dated invoice date usually signals a data-entry mistake.

The posting date, not the invoice date, typically needs to move into the current open period — some systems (Dynamics 365 is one) offer an automatic-adjustment setting so a pending invoice's posting date shifts to the current period rather than requiring a manual fix on every invoice.

Sources

Diagnostic

How do I shorten the close when AP reconciliation is the bottleneck?

Move AP-to-bank reconciliation to a rolling, weekly cadence instead of a single close-week event, so most of the matching work is already done by the time the period ends. Most AP bottlenecks at close aren't caused by close-week work itself — they're a backlog of sync gaps and unmatched payments that accumulated all month and only get discovered when someone finally looks.

Definition

What is an AR aging report and how do I read it?

An AR aging report lists every open invoice grouped by how long it's been outstanding — current, 1-30, 31-60, 61-90, and 90+ days past due. Read it by tracking the bucket distribution over time, not just the total; a shrinking current bucket and growing 90+ bucket signal a collections problem before it shows up in a blended DSO figure.

Topic

AP & Invoice Processing

Accounts payable and invoice processing is the set of steps a vendor bill goes through between arriving at a company and turning into a payment: capturing what the vendor sent, checking it against wha…

Diagnostic

Why does one vendor show two different balances in AP aging?

The vendor almost certainly exists as two separate records in your vendor master file — created under slightly different names (a typo, a rebrand, a merger, a re-onboarding) — so bills and credits are split across both. AP aging reports by vendor record, not by real-world vendor, so it shows two partial balances instead of one true balance.