Date of Receipt: Essential for Accounting & Tax Compliance
Understand the date of receipt in accounting and invoicing. Learn its importance for reconciliation, tax deadlines, and practical determination with examples.
A familiar problem lands on the finance desk every month. A supplier says an invoice was received last week. Accounts payable says it only hit the shared inbox yesterday. The controller is trying to close the period, and someone else is using the invoice date from the PDF because it's the easiest field to grab.
That's how late-payment disputes, cutoff errors, and weak audit trails start.
The date of receipt sounds simple, but it often isn't. In practice, we're dealing with several different dates that look similar on paper and mean very different things in accounting, tax, and payment workflows. If we don't separate them clearly, we can age payables incorrectly, recognize costs in the wrong period, or miss the evidence needed to defend a filing or payment timeline.
Table of Contents
- Introduction and Definition
- Why Date of Receipt Matters
- Regulatory Context in Accounting
- Determining Receipt Date on Invoices
- Determining Receipt Date on Bank Statements
- Practical Examples and Scenarios
- Quick Reference and Checklist
- Glossary and Related Resources
Introduction and Definition
In plain English, the date of receipt is the date a document, goods, or services are received under the rule that applies to that transaction. It is not automatically the invoice date. It is not the approval date. It is not the date someone keyed the item into the ledger.
That distinction matters because each date answers a different question:
- Invoice date tells us when the sender created the invoice.
- Date of receipt tells us when we received the document, goods, or services for the purpose that governs payment or recognition.
- Approval date tells us when an internal reviewer signed off.
- Posting date tells us when accounting entered the item into the system.
A simple way to think about it
Treat these dates like milestones in a parcel delivery.
The invoice date is when the sender packed the box. The date of receipt is when the box reached the right place. Approval date is when someone opened it and accepted it. Posting date is when someone logged it into inventory.
Those steps may happen on the same day. Often they don't.
Practical rule: If two dates serve different business purposes, store both. Don't force one field to do the work of four.
A good finance system should preserve separate fields for separate events. That applies whether we're handling supplier invoices, goods receipts, tax documents, or bank-statement support for reconciliation. Clear date fields make month-end close cleaner, vendor conversations easier, and audit questions much less painful.
Why Date of Receipt Matters
Organizations don't get into trouble because they lack documents. They get into trouble because the wrong date gets attached to the right document.
If we rely on invoice dates alone, we can start the payment clock too early or too late. If we rely on posting dates, we can shift expenses into the wrong period because the team was busy. If we mix up document receipt with goods receipt, we can approve payment before the underlying obligation is properly supported.
Where the confusion causes damage
A mis-recorded date of receipt affects several routine controls:
- Cash flow planning: Aging reports become less useful when invoices appear older or newer than they really are.
- Month-end close: Costs may be recognized in the wrong reporting period.
- Prompt-payment compliance: Payment timing may be tested against receipt of a valid invoice, not internal processing speed.
- Dispute resolution: Vendor claims are harder to resolve if we can't show when an item arrived.
- Tax support: Filing, evidence retention, and period assignment can depend on receipt-related dates.
Here's the practical accounting issue. A document can be valid, approved, and posted, but still have the wrong receipt date. That means the workflow looks complete while the control record is wrong.
Why finance teams should care early
The date of receipt is one of those fields that seems minor until someone challenges it. Then it becomes central.
A weak receipt-date record usually shows up at the worst time: during close, during an audit, or during a payment dispute.
For small business owners, this is often a spreadsheet problem. A single column named “received” may be carrying invoice arrival, service completion, and AP processing all at once. For larger teams, the problem is usually fragmentation. Email has one timestamp, the invoice portal has another, and the ERP stores a third.
The fix isn't complicated. We need a rule, evidence, and consistency.
Regulatory Context in Accounting
Government guidance is clearer on this than many internal workflows are. The common theme is that receipt is an evidence-based event, not a guess and not a back-office convenience date.
Australia's Treasury guidance states that the receipt date is the day an invoice is received by the reporting entity under the contract, and it distinguishes that from later entry or authorization dates. U.S. federal guidance follows the same logic by requiring agencies to use the actual invoice receipt date rather than the later scanning date, as summarized in Australia Treasury guidance on invoice receipt timing.
What the rules are really telling us
The lesson isn't limited to public-sector accounting. It applies to any finance process that needs defensible timing.
If an invoice arrives electronically outside normal working hours, some rules may push the effective receipt date to the next business day. If a paper invoice arrives and no one preserved the arrival evidence, fallback methods may apply. The point is that the legally meaningful date depends on what happened and what can be proved.
A useful control design separates at least these records:
| Field | What it answers |
|---|---|
| Document receipt date | When did the organization receive the document? |
| Goods or service receipt date | When did the economic event happen? |
| Approval date | When did internal review occur? |
| Posting date | When did accounting record it? |
Evidence matters more than convenience
A team may be tempted to default to the date visible at the top of the invoice because it's easy to capture. That's risky. The strongest workflow preserves the timestamp, channel, and supporting evidence for receipt.
For teams reviewing older records, bank record retention guidance is a useful reminder that supporting evidence doesn't stay available forever. If receipt timing may matter later, preserve it when the document arrives.
Determining Receipt Date on Invoices
When we determine the date of receipt on an invoice, we should think like reviewers, not data entry clerks. Our job is to identify the date that the rules and the evidence support, then keep that support attached to the record.
Connecticut state guidance draws an important line here. It defines receipt date as the date goods or services were received or became contractually due, requires the latest date to be used when an invoice includes multiple dates, and says the receipt should be recorded within seven calendar days after a proper invoice reaches Accounts Payable in Connecticut accounting memo guidance.
A practical sequence for invoice review
Use a simple order of review:
- Start with direct evidence of arrival. Check an official receipt stamp, shared-mailbox timestamp, portal delivery log, or documented hand-delivery record.
- Separate document receipt from economic receipt. If the invoice covers delivered goods or completed services, capture that date separately.
- Review multi-date invoices carefully. If one invoice covers several deliveries or a service period, use the latest applicable date where the governing rule requires it.
- Keep the source. Save the email header, portal screenshot, receiving report, or stamped image that supports the date.
Common places teams get tripped up
Two invoice dates can both be real and still answer different questions.
A supplier may issue an invoice on Monday, your inbox may receive it on Tuesday night, and the goods may have been delivered earlier. None of those dates cancels the others out. They belong in different fields.
For teams building invoice capture templates, it helps to compare fields against the standard parts shown in this breakdown of what appears on an invoice. The visual layout often puts the invoice date in the most prominent place, but prominence doesn't make it the right receipt date.
Don't let layout position make the decision. The biggest date on the page is often the least useful one for compliance.
What to store in the record
At minimum, keep:
- Normalized receipt date: The standardized date used in the accounting workflow.
- Original source value: The raw date exactly as shown in the document or system.
- Channel of receipt: Email, portal, paper, courier, or hand delivery.
- Evidence reference: Stamp, delivery log, receiving report, or acknowledgment.
That gives us a file we can defend later, even if the invoice itself contains several plausible dates.
Determining Receipt Date on Bank Statements
Bank statements are different from invoices because they often contain several time layers at once. There's the statement issue date, the transaction date, the posting date shown by the bank, and the date your team received the statement file.
That means we shouldn't ask one broad question like “What's the receipt date on this statement?” We should ask, “Receipt date of what?”
Distinguish the statement dates first
Before using statement data in bookkeeping, separate these ideas:
- Statement issue date: When the bank generated or made the statement available.
- Transaction date: The date shown for the underlying debit or credit.
- Posting date: The bank's ledger date if separately shown.
- File receipt date: When your team downloaded, received, or imported the statement.
Those dates can all be useful. They are not interchangeable.
If your source is a PDF, many teams first convert it into a spreadsheet for review. A practical reference point is how bank account statements are structured and read, because statement layouts differ widely by bank.
The control that catches bad extraction
When parsed statement data is going into a reconciliation workflow, we should test the arithmetic before trusting the rows.
Opening balance + total credits - total debits = closing balance.
That control helps identify omitted transactions, duplicated rows, reversed debit and credit signs, or OCR errors before the file reaches bookkeeping or tax work. It's one of the most useful checks because it tests the statement as a whole rather than trusting each extracted line item in isolation.
A sensible workflow for statement-based support
Use this sequence:
| Step | What we check |
|---|---|
| Identify the statement-level dates | Confirm issue date and statement period |
| Review transaction-level dates | Note transaction and posting dates if both appear |
| Validate statement arithmetic | Test opening balance plus credits minus debits equals closing balance |
| Preserve the source PDF | Keep the original document for later review |
If the extracted rows don't reconcile back to the statement totals, the problem is the data set until proven otherwise.
That mindset keeps us from building downstream work on top of a preventable parsing mistake.
Practical Examples and Scenarios
The easiest way to get date-of-receipt rules right is to walk through ordinary cases.
After-hours electronic delivery
A small business receives an invoice by email late in the evening. The PDF shows an invoice date from earlier that day, but the payable team won't see the message until the next business morning.
In some rule sets, after-hours electronic delivery may shift the effective receipt date to the next business day. That means the sent time, inbox delivery time, and effective receipt date may all differ. The accounting team should preserve the email timestamp and apply its documented rule consistently.
This is also where teams confuse “sent” with “received.” They are not the same.
Multi-date service invoice
A consulting invoice covers work performed across several dates in one billing period. The vendor's PDF includes the invoice issue date, a service period, and a payment due date.
In this situation, the correct accounting treatment may depend on the latest applicable service or contractual date, not the printed invoice date. That's why one unlabeled “receipt” field is too blunt. We need a document-received date and a service-related date stored separately.
Dispute over portal delivery
A vendor claims an invoice was available in the customer portal before month-end. Accounts payable says it wasn't routed internally until later.
The strongest evidence here is usually the portal log showing when the invoice became available to the receiving party, plus any acknowledgment or system notification. Internal routing delays don't usually change the fact of external delivery. What they change is processing speed.
Electronic notice timing in the UK
UK regulations add another useful lesson. They treat an electronically sent notice as given at 9 a.m. on the next working day unless proven otherwise in UK regulation 23 on electronic notices. That rule highlights why we must distinguish sent, delivered, and received timestamps.
For finance teams, the takeaway is simple. A system log may show transmission on one date, while the legally effective date lands later.
Good evidence doesn't always tell us only what happened. It tells us which date rule applies to what happened.
Bank statement support during close
A bookkeeper receives a scanned bank statement PDF from a client and extracts the transactions into a spreadsheet. The rows look reasonable, but one debit sign is reversed and a line is duplicated.
If the team posts the data without checking the statement arithmetic, the reconciliation will drift and the wrong period may absorb the error. If the team tests opening balance plus credits minus debits against the closing balance first, the extraction issue surfaces before posting.
That's why statement review is part accounting judgment and part data control.
Quick Reference and Checklist
A quick checklist works better than a long policy when the team is moving fast.
Fast lookup guide
| Document type | Best evidence for date of receipt |
|---|---|
| Invoice | Official stamp, email timestamp, portal log, receiving inbox record |
| Goods delivery note | Signed receiving documentation, dated acknowledgment, packing slip support |
| Service invoice | Service completion date, contractual due date, supporting approval record |
| Bank statement | Statement availability date, transaction dates, original PDF, extracted table review |
General rules we should apply
- Prefer evidence over appearance: The printed document date may be real, but it may not be the receipt date.
- Keep separate fields: Document receipt, goods or service receipt, approval, and posting shouldn't collapse into one column.
- Flag conflicts instead of guessing: If two dates compete, retain both and document which rule controlled.
- Treat after-hours items carefully: Business-day rules may affect the effective date.
- Reconcile statement data before use: Verify opening balance plus credits minus debits equals closing balance.
A good checklist doesn't eliminate judgment. It makes judgment more consistent.
Glossary and Related Resources
Date of receipt means the date a document, goods, or services are received under the applicable rule and evidence.
Invoice date is the date the supplier issued the invoice.
Posting date is the date the item was entered into the accounting system.
Tax point for UK VAT isn't automatically the same as document receipt. HMRC explains that the tax point is generally tied to invoice issue, payment under cash accounting, or the date of supply depending on the situation in HMRC VAT record guidance.
Electronic invoice retention also matters. HMRC says electronic invoices must contain the same information as paper invoices and are normally retained for six years in HMRC electronic invoicing guidance.
If you need statement data in a workable format before reviewing transaction dates and balance controls, autobankstatement converts PDF bank statements, including scanned and password-protected files, into CSV or Excel/XLSX. It supports bulk upload, files up to 25 MB, a free guest preview before payment, and temporary handling with uploads auto-deleted within 24 hours, which makes it practical for finance teams cleaning up receipt-date evidence from bank PDFs.
Convert your next statement in minutes
Upload a bank statement PDF — digital, scanned, or password-protected — preview the extracted table, and download clean CSV or Excel.