Invoice date or payment date? Keep your EDF timeline clear

Understand the different dates in an export record and avoid mixing invoicing, settlement and bank-credit events.

One export can have a contract date, invoice date, payment initiation date, settlement date and bank-credit date. Each describes a different event. A timeline that collapses them into one “transaction date” makes reconciliation and deadline questions harder than they need to be.

Record events in separate fields

Use the original invoice issue date and keep a separate field for any due date agreed with the customer. When payment arrives, record the evidence date and transfer reference without overwriting the invoice date. If a provider reports initiation and settlement on different days, keep both and label them clearly. Time-zone differences should be explained using the original statement rather than guessed away.

Use the correct date for each question

Before using a calculator, identify which event the applicable rule uses. A monthly preparation list, the customer’s payment terms and the permitted realisation period answer different questions. Ask the bank about an ambiguous or corrected invoice date. Keep the answer with the source document instead of editing dates merely to obtain a preferred result.

Distinguish a date correction from a later event

A genuine error in the invoice may need a correcting document. That is different from payment arriving later or a provider settling on another day. Preserve the original invoice and the reason for any actual correction. Ask how an already submitted record should be updated instead of overwriting its date in the working schedule.

If your accounting system exports both created and issued timestamps, identify which field represents the invoice you provided to the customer. Keep the original evidence when the two differ. Do not use a convenient system timestamp to move a transaction into a preferred period. A reviewer should be able to follow the commercial event without relying on an unexplained column called date.

Read cross-border timestamps carefully

A customer or provider may show a payment event in a different time zone from the Indian account statement. Preserve the original timestamp and its stated zone where available. If you make a local-time working view, label it as a conversion and retain the original. Avoid changing the source evidence to make two systems appear identical.

Also distinguish authorised, initiated, processed, settled and credited events. A screenshot saying payment initiated does not establish the final credit date. Ask the provider for transaction details when the difference matters. Link the transfer identifier across the timeline so the reviewer can recognise one payment passing through stages rather than several separate payments with similar amounts.

Review period boundaries before calculating dates

At month-end, list invoices near the boundary and check their original issue dates. Then inspect later receipts separately. This is particularly helpful when a platform releases a batch after the earning or invoice period. Keep the customer due date and any authority-confirmed extension in their own fields rather than storing them as replacements for the original date.

Before using a deadline result, write down the event and route you selected. The correct calculation depends on the applicable process and facts. If you are handling a historical case or a disputed invoice date, ask the bank for the relevant treatment. Retain the response with the timeline so another person can understand why a particular date was used.

A fictional example

An invoice is issued on 28 October, the customer initiates payment on 31 October and the account is credited on 2 November. The record retains all three events. The invoice is not moved into November simply because the bank credit occurred then.

Preparation checklist

Preserve the invoice’s original date.
Label the provider’s event dates explicitly.
Separate customer due dates from regulatory calculations.

Can a pending payment be left out of my working invoice list?

Keep it visible. Pending status is useful information; it should not make the underlying invoice disappear.

FICTIONAL WALKTHROUGH

A month-end payment with three timestamps

A fictional invoice is issued on 30 October. The customer authorises payment late on 31 October in its own time zone. The provider reports settlement on 1 November and the Indian account shows credit on 2 November. All events are kept with their original labels.
The working invoice list retains the October issue date. The receipt list includes the settlement and credit references. The preparer does not alter the invoice to November or treat the customer authorisation screenshot as proof of the final bank credit.
The bank enquiry asks how to represent the receipt route and supplies the linked timeline. Any date calculation is stored with its selected starting event, leaving the original evidence unchanged and available for later review.

Your next step

Calculate an illustrative date

Sources and scope

Sources reviewed 9 October 2026. The routines and fictional examples are editorial preparation suggestions. They do not confirm your bank’s acceptance, classification or transaction status.