Cargo Scheduling: Why the Plan Is Binding Before Anything Records It

Summary

Cargo scheduling reads like an internal planning activity — a calendar, a set of allocations, a question of who lifts what and when. It is not. Almost every step of it is a declaration made to somebody outside your company, and each one takes effect when it is sent, not when it is entered into a system.

This article sets out where those commitments actually live, why the trading system usually learns about them last, and why the cost of getting them wrong shows up in places that do not look like scheduling problems at all: a demurrage claim, a hedge dated to the wrong month, an invoice two parties cannot agree on.

Read it if you run a physical book and your operations plan lives in a spreadsheet and an inbox. Start with the next section — the rest of the article follows from it.

The schedule is a register of promises, not a plan

A trade contract establishes what you owe. The schedule establishes when, to whom, in what, and from where — and unlike the contract, it is not negotiated once and signed. It is assembled over weeks out of individual declarations: a nomination, an acceptance, a vessel name, a laycan narrowing, a loading port, a discharge instruction.

Each of those declarations is outbound. It leaves your company and lands with a counterparty, a terminal, a port agency, an inspector. From that moment it you, whether or not anything internal has recorded it.

That is the property worth holding onto: a scheduling commitment is binding from the moment it is sent, and it is recorded — if at all — afterwards.

Everything else in the trade lifecycle works the other way round. A trade is captured and then it exists. A hedge is executed and then it appears. A payment is instructed and then it moves. Scheduling is the one part where the authoritative act happens in an email client, and the system of record catches up later.

This is why "we have a scheduling module" so rarely resolves the problem. The module is downstream of the act. It records that a nomination was made; it is not the thing that made it.

The paper book is dated by month, and the cargo is dated by a window

A hedge has a contract month. A cargo has a laycan — a window of a few days, and often one that has been narrowed twice before it is final.

Those two datings are not the same kind of object, and they do not move together. A cargo that slips does not take its hedge with it. When a loading window moves across a month boundary, the physical leg has changed period and the paper leg has not, and nothing about that shows up as an error. Both positions are still correct. They are simply no longer describing the same delivery.

A scheduling change is a repricing event that arrives without a price.

The mismatch is not a quantity mismatch, and this is what makes it easy to miss. Quantity reconciliation is a familiar discipline — it has a number on each side and a difference in the middle. A dating mismatch has no difference to compute until the month closes and the basis has already moved.

Everyone on the cargo holds a different copy of the plan

A single cargo typically involves the seller, the buyer, a terminal or berth operator, a vessel owner or charterer, a port agency at each end, and an independent inspector. Each of them learns of a change through a separate message, sent at a different time, sometimes by a different person on your side.

There is no shared copy. There is a set of copies, and the one that governs any given party's behaviour is whichever message they last acted on.

A schedule distributed by email does not have versions; it has recipients.

This is the structural reason scheduling disputes are so hard to settle after the fact. There is no single artefact to point at. The reconstruction has to be done out of a mail thread, and the mail thread is the record — which is precisely why so much operational effort goes into forwarding, copying and confirming rather than into scheduling itself.

It is also why the fix is rarely "be more careful". Care distributes the same number of copies.

Where the same cargo appears, and under what name

One reason the schedule resists being reconciled with anything is that it does not share an identifier with the things it has to be reconciled against.

None of these keys derives from the others. One contract can become several cargoes; one cargo can carry parcels belonging to several contracts; one voyage can serve several counterparties. The joins between these records are made by people, repeatedly, and mostly by hand.

Reconciliation is manual here not because nobody has automated it, but because the records were never keyed to each other in the first place.

Optionality is spent one declaration at a time, and nothing records the spending

Physical contracts carry choices. Which window inside the delivery period. Which grade, where the contract allows a range. Which loading port, where more than one is nominated. Which vessel. Sometimes which of two discharge options.

Each of those choices has value, and a declaration spends one of them — getting it back requires the other side's agreement, which is a negotiation rather than a correction. Nominate a three-day window inside a ten-day delivery period and the other seven days stop being yours to use. Declare a grade and the alternative is off the table.

The trading system records the outcome — what was lifted, when, of what. It does not usually record the moment the option was given up, or what was given up, or by whom, or why.

An operations team spends contractual optionality every week, and in most organisations there is no ledger of that spending.

This is not an argument for hesitating. Nominations have deadlines; declining to decide is itself a declaration, usually a worse one. It is an argument that the declarations are decisions with commercial content, and they are being treated as administrative steps.

The cost never lands in the function that caused it

Scheduling errors do not produce scheduling losses. They produce:

• A demurrage claim, which lands in operations or claims, weeks later, as a document to be verified rather than as a decision to be reviewed.
• A basis break, which lands in risk as a position that no longer offsets.
• An invoice dispute, which lands in settlement as a difference between two parties' quantity or date, with the underlying cause several steps upstream.
• A counterparty conversation, which lands with the trader who owns the relationship, and which is rarely written down anywhere as a cost at all.

Because the cost surfaces elsewhere, the function that generated it is the one least likely to be measured on it. The scheduling desk is measured on whether cargoes moved. They did. The consequences are in four other ledgers.

Where a cost is recognised decides who tries to prevent it — and scheduling costs are recognised everywhere except in scheduling.

What governs each deadline, and who sets it

Scheduling deadlines are not internal. They come out of the contract and out of third parties' operating rules, which means they run on somebody else's clock.

The table is worth reading as a whole rather than row by row. The deadlines that govern a cargo are set by somebody who is not you, and each one converts a missed internal step into an external, priced consequence. There is no equivalent of "we will catch it in the month-end close".

Three observations that locate this in your own operation

None of these requires a study. They are things you can establish this week.

First: ask where the current version of next month's plan is. If the answer is a file name plus a person's name — the version on someone's machine, the one they send round — the schedule is not in a system, whatever the system contains.

Second: take one cargo that moved last quarter and try to reconstruct why its window ended up where it did. If that requires reading a mail thread, then the mail thread is the record, and it is a record with no access control, no retention rule and no queryable structure.

Third: find out who knows a laycan has moved, and how long it takes them to know it. Not who is on the email — who acts on it. Risk, settlement and inventory each need that fact for different reasons, and in most operations they learn it at different times, from different people, if at all.

If all three land uncomfortably, the constraint is not the scheduling process. It is that the scheduling process has no system of record, and everything downstream is inheriting that.

Questions people ask about this

Is cargo scheduling not just an operations task?

It is executed by operations, and the choices it makes are commercial. A window, a grade, a port and a vessel each carry value under the contract, and each one is given away permanently the moment it is declared. Treating those declarations as administrative is what makes their commercial content invisible — not the fact that operations makes them.

Our ETRM has a scheduling module. Why is the work still in spreadsheets?

Because the module records nominations and the spreadsheet makes them. Scheduling work is largely the assembly of a plan out of partial, changing information from several outside parties — what a berth can take, when a vessel is free, which counterparty will accept a narrowing. A form that captures the finished decision does not help with assembling it, so the assembly stays where it is flexible, and the system receives the result. This is usually a reasonable local choice, and it is worth recognising as the reason rather than as a failure of discipline.

Who should own the schedule, operations or trading?

The more useful question is which parts have to be visible outside the team that owns it. Ownership can reasonably sit with operations. But at least four other functions need to see a scheduling change quickly and for different reasons — risk because the hedge is dated, settlement because the invoice will be, inventory because the position will move, and the trader because a counterparty will call. Ownership settles who decides. It does not settle who has to be told.

How is demurrage exposure different from scheduling exposure?

Demurrage is what you can be billed for once the clock has started. Scheduling exposure is everything that determines whether it starts, and it is decided earlier — at nomination, at laycan narrowing, at the choice of berth. By the time a demurrage claim is a document being checked, the decisions that produced it are several weeks old. Verifying claims accurately and managing the exposure that creates them are two different activities, and only the first has an obvious owner in most companies.

Can the terminal's or counterparty's portal be our system of record?

It can be authoritative for what that party believes, which is not the same thing. A portal shows one counterparty's view of one part of the plan. You need the whole plan, across counterparties, joined to your trades and your positions, and retained after the relationship ends. Portals are worth reading from. They do not compose into a record of your own commitments.

What breaks first when cargo volume grows?

The joins. A small operation can hold the mapping between trades, cargoes, voyages and invoices in a few people's heads, and that works better than it should. What fails is not the volume of scheduling work — it is the number of relationships between records that a person is silently maintaining. That number grows faster than the cargo count, and it fails without warning, usually when one of those people is unavailable.

Do we need a scheduling system, or better discipline in the one we have?

Answer a narrower question first: when a laycan moves, what has to happen, and who currently makes it happen? If the answer is a person remembering to tell four other people, no amount of discipline fixes it — discipline is what is holding it together already. If the answer is that the change is recorded once and the other four read it, the process is sound and the tooling question is about effort, not about risk.

Where this lands in a trading system

The argument above is about physical trading operations generally. This section is about what a system can and cannot settle, and it is deliberately narrower.

Three of the conclusions map onto capabilities the trading and risk system you already run should be expected to cover. The schedule needs to live where the trade lives, which is a matter of end-to-end logistics coordination and execution management. The dating problem between the physical leg and the paper leg is why physical trade, financial hedging, risk control and settlement being in one platform matters more here than in most parts of the lifecycle — the two legs have to be comparable to be reconciled. And the movement that a scheduling change implies is an inventory change, which is real-time inventory tracking rather than a separate discipline.

The fourth conclusion — that the plan is assembled outside the systems of record, in spreadsheets and mail — maps onto something different. X-Ray is a non-invasive data processing and analysis platform, and the part of it that matters here is XDK: non-invasive automated data collection from databases, Excel files, and web interfaces, designed to collect data without disrupting existing systems or workflows. Where the working plan genuinely does live in a spreadsheet, that is a way to read it without first insisting it move. X-Eagle provides real-time risk alerts and monitoring for trade finance field warnings; whether that shape — a watched field, a threshold, a notification — is pointed at a nomination deadline is a configuration question rather than something a platform decides for you, but a deadline on a field is an ordinary shape, not an exotic one.

None of this schedules a cargo. It does not choose a laycan, negotiate a narrowing with a counterparty, or tell you which vessel to nominate. Those are judgements made by people with commercial authority, and they will stay that way. What a system settles is narrower and duller: where the declaration is recorded, how quickly the other four functions can see it, and whether the mapping between a trade, a cargo, a voyage and an invoice survives the person who has been holding it in their head.

See the products → · Talk to us about physical operations →

A note on the evidence in this article

This article contains no statistics, and that is deliberate rather than an oversight.

The material we hold on how these processes actually run — where the manual effort concentrates, which steps depend on spreadsheets and mail — comes from research we are not in a position to publish as a citable source. Publishing a number we cannot point you to would be worse than publishing none: it would look like evidence and could not be checked.

So the argument here runs on structure instead. Each claim is meant to be testable against your own operation rather than accepted on our authority: the declarations really do leave before they are recorded, the hedge really is dated differently from the cargo, and the four ledgers really do carry different keys. If any of that does not describe your business, the conclusions should not carry weight with you.

Author and date

Time Dynamics

First published: (to be filled on publication)