Invoice date versus payment date: the same week can contain different sales

Name the event behind the date

Possible fields include invoice date, service date, payment date, refund date and export creation time. They describe different events. Before comparing reports, inspect the report definition or field description and write the chosen event beside the start and end dates.

The filename “September sales” is not enough evidence. Keep the original report name, selected filters, date field and export time in a source register. If a provider’s meaning is unclear, verify its current documentation or ask for clarification rather than assuming a field called “Date” means the service date.

See which rows move across the boundary

This fictional example compares 25–27 September 2026, inclusive. All amounts are AUD. Each sale has one payment; fees, deposits, part-payments and refunds are deliberately absent so the timing effect is isolated.

The invoice-date report contains S-511 and S-512, totalling $165.00. The payment-date report contains S-510 and S-512, totalling $275.00. The $110.00 difference does not identify an error; it identifies different membership.

Bridge one total to the other by reference

Start with the invoice-date total of $165.00. Add $220.00 for the earlier invoice paid inside the period. Remove $110.00 for the current-period invoice paid after the period. The result is $275.00, matching the payment-date report.

Keep both the amount and the reference in that bridge. A single net adjustment of $110.00 conceals two separate timing items. In a later period those items may reverse, so the outstanding-reference list is more useful than a balancing number.

Choose the source that matches the recorded commission process

The comparison does not decide whether commission should follow a sale, completed service or received payment. That decision belongs in the documented arrangement and operating process. Select an export that supplies the required event and item detail once that basis is known.

Trimsum filters the date mapped from the CSV into the selected inclusive period. It does not infer a second date, join payments to invoices or reconstruct instalments. If your process depends on matching several payment events to one service, prepare and verify that evidence before treating a flat itemised import as complete.

Check the boundary as well as the field

Do not convert a source timestamp into a different calendar day without recording the reason. A date-only commission record needs a deliberate source-day convention, especially when exports from different systems use different timezones.

1. Confirm the start and end dates are inclusive and use the same convention in both reports.
2. Identify the source system’s timezone when events include times near midnight.
3. Check the date format explicitly; 09/10 is ambiguous without a convention.
4. Inspect a known transaction just before the start, on each boundary and just after the end.
5. Separate rows outside the intended period before comparing accepted totals.

Keep timing differences out of duplicate and error fixes

An earlier invoice paid this week is not a duplicate merely because the invoice already appeared in last week’s sales report. Likewise, a sale missing from this week’s payment report is not necessarily missing money. Check the event and the reference before excluding anything.

If part-payments, refunds or settlement fees exist, extend the bridge with their actual source records rather than reusing the simplified example unchanged. The date-range checker can identify membership within one chosen date field; it cannot decide what the field ought to mean.