Your statement period is not a calendar month

Card statements close on a cycle day. Ledgers close on a calendar month. Those two dates are usually different, and almost every recurring month-end argument about corporate card spend traces back to that one fact.

It is a small piece of plumbing that quietly shapes reporting, reimbursement, and whether your expense tool looks empty on the first working day of the month.

What a cycle day is

Every card account has a closing day — the 4th, the 15th, the 22nd. Charges that settle between one closing day and the next belong to that statement. If your cycle day is the 22nd, the statement you receive in August covers roughly 22 July to 21 August.

Cardholders think in statements, because that is what arrives and that is what gets paid. Finance thinks in months, because that is what the ledger and the VAT return are built on. Both are correct. They are simply not the same window.

Three things this breaks

Spend that appears to double-count. A department head looks at “this month’s card spend” and compares it against the statement total. The numbers do not agree, because the two views cover different ranges. Nobody is wrong and nobody can prove it, which is the worst kind of disagreement.

Charges that land in the wrong period. A charge made on 30 June that settles on 2 July belongs to July’s ledger, not June’s. Teams that reconcile from the statement rather than the settlement date will file it in the wrong month and then find it again during the year-end review.

Dashboards that look broken. This one is subtle and it catches product teams as often as finance teams. If a tool defaults its view to the current statement period, then on the first days of a new cycle that view is legitimately near-empty — the period has barely started. The data is fine. The default view just cannot see it. An empty screen reads as “this is broken” to almost everyone who encounters it.

Pick one truth, then be explicit about it

The fix is not to force the two calendars to agree — you cannot; the card issuer owns one of them. The fix is to decide which window each artefact uses, and say so on the artefact itself.

Reconcile by settlement date, in calendar months. The ledger is the system of record and it runs on months. Reconciling to the month keeps VAT returns and management reporting aligned, and it is the version your accountant expects.

Reimburse and pay by statement. The statement is what the card company bills. Matching payment to the statement keeps the account clean regardless of how the ledger sliced it.

Label every total with its range. “August” is ambiguous. “1–31 August” and “22 Jul – 21 Aug” are not. A date range printed next to a number ends the argument before it starts.

What to check in a tool

If you are evaluating expense software, three questions are worth asking early, because retrofitting any of them is painful.

Can the statement cycle day be configured per workspace, or does it assume the 1st? Can a report be run over an arbitrary date range, not just the preset period? And when the current period is empty, does the interface say so clearly — or does it say something that reads like “you have no data”?

Rexa stores a statement cycle day per workspace and keys its period views off that rather than the calendar, so “this period” means what a cardholder expects it to mean. Exports and period close run on calendar months, because that is what the ledger needs. Both views exist because both are needed; the important part is that each one is labelled.

General information, not tax or accounting advice. Confirm period-allocation treatment with your accountant.