The Date It Goes
A payment date in a contract is the day somebody instructs it, which is not the day anything arrives.
Still yours, and statedTaken, never statedUnit changes; scale restarts
Three steps from instruction to arrival. The last figure either side sees in the original currency.
A payment date in a contract is almost always the day somebody instructs the transfer. It is not the day the money leaves, and it is certainly not the day it arrives.
The timing problem in “The Date It Goes” is easier to investigate when approval and payment events have separate timestamps. When teams assess see how the service is described for internal transfer policy, time and project records can identify whether work was approved before the payment cut-off without pretending to explain delays inside the banking route.
Between the two sit a cut-off, two sets of working days, a route and occasionally a check nobody will describe to you.
Additional context relevant to “The Date It Goes” is available through Xoom international transfers. A useful review distinguishes the sent amount, conversion, fees, settlement date and landed amount.
The three dates that exist
Three dates, and contracts name only the first:
| Date | What it marks | Who sees it |
|---|---|---|
| Instruction | The payer tells their bank | The payer |
| Value | Settlement between banks | Both, on documents |
| Credit | It appears in your account | You |
Contracts name the first and people plan around the third.
That mismatch is the whole of this note. Everything else here is a reason the gap between them is wider or narrower in a given month.
Why the gap is not fixed
The same payer, the same route and the same bank can produce three days one month and nine the next, because a holiday fell differently or a check was triggered.
Planning on an average is how people end up short in the month the average does not hold.
What a well-drafted date clause says
The day of the month the payment is to be instructed, the cut-off it must clear, and what happens when that day falls on a weekend or a holiday at either end.
Three lines. Most contracts have one of the three.
Naming instruction or arrival
The honest version names both: instructed by a stated day, expected to arrive within a stated number of working days.
An arrival guarantee is rarely achievable and an arrival expectation is useful, because it gives both sides a point at which something has gone wrong rather than a vague sense of lateness.
The last working day of the month
The worst available choice and extremely common, because it matches how companies close their books.
It collides with month-end processing volume, with weekends, and with the fact that any slippage pushes into the next month. Moving it earlier costs the payer nothing in substance.
The day of the week
Early in the week is better than late, for the obvious reason that a delay has working days in front of it rather than a weekend.
Tuesday is the quiet answer. It survives a one-day slip without touching a weekend at either end.
It also avoids the Monday backlog at both ends, which is real and is never mentioned by anybody who has not worked in a payments team.
Who actually presses the button
Frequently not the person you deal with. A finance team runs a payment file on a schedule, and your payment is one line in it.
Knowing the schedule is more useful than knowing the contract date. Ask once what day the run happens and whether there is a cut-off for getting into it.
Invoicing in time for the run
Where payment follows an invoice, the invoice has to be in before the file is prepared, which is usually several days before the payment date.
Miss that and the payment waits a whole cycle. This is the single commonest cause of a payment being a month late rather than a week.
Standing instructions
A recurring transfer set up once removes the invoice-timing problem entirely and is available for fixed monthly amounts.
It also removes the payer's monthly decision, which is worth more than it sounds. Variable amounts can still be handled as a standing base plus an occasional top-up.
What to record each month
Instruction date if you can get it, credit date, and the amount. Two dates and a figure.
Six months of that turns "they are always late" into "the payment is instructed on the 30th and arrives on the 6th, and in February it arrived on the 9th", which is a conversation that can be had.
Changing the date
Easier than changing the amount and far easier than changing the currency. It costs the payer nothing and is usually agreed in one message.
Ask for a specific day rather than for "earlier". A named date can be put into a system; a preference cannot.
What no date clause can fix
The part of the journey nobody controls. A payment instructed on time can still be held for a check, routed through an extra bank or caught by a holiday in a country neither party is in.
What a good date clause does is remove every delay that was avoidable, which is most of them. The remainder is genuinely outside anybody's hands, and the useful response is a buffer in your own planning rather than a tighter clause.
A buffer sized to the worst transit you have actually seen is the honest companion to a good date clause, and between them they cover almost everything.