Contract Received: When Can the Trade Be Entered and Confirmed?

Receiving a contract does not mean the trade is ready to be entered and confirmed. In crude oil operations, the first step is to check whether the document reflects terms agreed by both parties or a version still under discussion. The next step is to check whether those terms can be mapped accurately to the ETRM system, and whether anything is missing, conflicting or open to interpretation.

Complete, consistent information can be entered and submitted for review under internal procedures. Agreed terms can be entered first, but outstanding items must remain pending. Key uncertainties about the contracting entity, price or quantity option need to be resolved first. An agent can extract information, compare versions and prepare draft entries. It cannot use default values to make an unconfirmed trade appear complete.

This article focuses on the checks between contract receipt and ETRM entry. For vessel tracking, document checks, settlement and payments, and the agent's role at each stage, see AI Agents in Crude Oil Trade Execution: Which Tasks Can Be Delegated?.

1. Confirm the basis for entry before filling in fields

Contract receipt usually involves several documents: the trader's deal recap, confirmation emails from the counterparty, the contract PDF, the applicable General Terms and Conditions, and any later amendments.

The first step is to link these documents to the same trade and check the status of each:

Has the recap been confirmed by both parties, or is there only an internal deal record?
Is the contract an initial draft, a version awaiting revision, or a version that has completed the required confirmation process?
Are later emails proposing changes or confirming them?
Has each amendment been accepted, and which terms does it change?
Which set and version of the general terms and conditions does the contract reference?

The latest document received is not necessarily the latest agreed version. A filename containing “final” is no substitute for a record of confirmation by both parties.

In Shell's published contract structure, for example, the Special Provisions and General Terms and Conditions together form the contract. Some terms needed for execution may therefore sit in the referenced general terms. Checking only the first page and the commercial terms table is not enough.

Source document: Shell — General Trading Terms and Conditions.

The absence of a signed contract does not necessarily prevent trade entry. Whether a trade can be created from a confirmed recap depends on internal trade entry procedures and the available confirmation records. Three things must remain distinct: whether the trade terms are confirmed, whether the contract documents are complete, and whether the system record has been reviewed. They cannot be combined into a single “complete” status.

2. Check each field: A value is not enough if its meaning is unclear

Pre-entry checks involve more than copying text from a PDF into the matching field. Each field needs a clear source, a clear business meaning and an accurate system mapping.

Item	What to confirm before entry	Common errors
Counterparty	The buyer and seller legal entities, the internal contracting entity, and the matching ETRM master data	Using a group name, a company from an email signature or a similarly named entity as the contracting party
Buy/sell	Whether the trade is a purchase or sale from the internal contracting entity's perspective	Copying the direction from the counterparty's document, or treating the purchase and sale of the same cargo as one trade
Grade	The contracted crude grade, the matching grade code and the applicable quality terms	Selecting a product code based only on a similar name and missing a different quality basis
Quantity	Contract quantity, unit of measure, tolerance, who holds the quantity option, and the applicable basis for determining quantity	Entering only the base quantity and omitting the tolerance and option holder; confusing contract quantity with later actual quantity
Laycan	Start and end dates, the year, and any agreed process for narrowing the window later	Entering a monthly supply arrangement as a fixed laycan, or confusing ETA with the loading window
Load/discharge port	Confirmed ports, the permitted range of options, who holds the option and the deadline for confirmation	Selecting one port from an agreed range without authority, or using a system default for an undecided port
Pricing formula	Price source, exact benchmark, differential and its sign, currency, price unit and adjustments	Entering only a benchmark abbreviation, or using the wrong differential sign or price unit
Pricing period	The pricing window, its relationship to events such as the B/L date, the applicable quotation days and averaging rules	Replacing the contractual pricing window with the loading month, or selecting fixed dates without a basis
Payment terms	Payment period, the event that starts it, date calculation rules, payment method and document conditions	Entering only the number of days and omitting the starting point or document requirements
Title transfer	The event, place or conditions for title transfer, with a separate check of risk transfer terms	Inferring title transfer solely from delivery terms such as FOB or CIF, or treating title and risk as the same
Versions and amendments	The currently confirmed terms, the scope of each change, the trade it applies to and the confirmation records	Mixing old and new terms, or overwriting the official record with changes that have not been accepted

An agreed pricing formula that depends on quotations not yet published is a normal dependency on future data. It is entirely different from the parties not having agreed which benchmark to use.

Likewise, an agreed title transfer provision is not incomplete just because the transfer event has not occurred. At this stage, the agreed rule is entered. Title must not be marked as transferred before the event occurs.

3. Case one: Information is complete and consistent, so the trade can be entered and submitted for confirmation

Entry can proceed when there is sufficient evidence of confirmation, no unresolved conflicts between key terms, and an accurate mapping to system fields.

The following conditions generally need to be met:

The current documents supporting the trade and their versions are clear;
Counterparty, buy/sell and grade can be mapped accurately;
Quantity, pricing, date and payment rules are clear;
Referenced general terms and confirmed amendments have been included in the checks;
There is no duplicate record of the trade in the system;
The person entering the trade has the required authority, and the review requirements are clear.

“Complete” does not mean that the loaded quantity, B/L date or final price must already be available. What must be complete are the terms that should be settled at this stage and the rules for determining future data.

Once these conditions are met, the trade can be entered and submitted for review under internal procedures. Moving it to confirmed status still depends on the required approvals and assigned responsibilities. Filling every mandatory field is not enough.

4. Case two: Agreed information can be entered, but outstanding items must remain pending

Some trades have clear commercial terms, while certain documents, operational details or internal checks remain outstanding. If internal procedures allow it, the confirmed information can be entered first, with the outstanding items clearly identified.

Common situations include:

There is evidence that the recap has been confirmed, but the formal contract documents are still outstanding;
The contract allows a port to be selected later from an agreed range, and the specific port has not yet been nominated;
A process for narrowing the loading window has been agreed, but the final window has not yet been notified;
The terms are clear, but the required master data or system configuration has not yet been set up.

Not every missing future data point should leave the whole trade pending. For example, if the pricing window is clearly defined by reference to the B/L date, but that date is not yet available, the event-based rule should normally be retained. This should not be labelled “pricing terms unconfirmed.”

A pending item should identify at least:

Which field or document remains outstanding;
The basis for the information already confirmed;
Who is responsible and when it needs to be completed;
Which later actions cannot proceed until it is resolved.

Pending cannot be just a note in a comments field. If draft records feed into Exposure, PnL or downstream workflows, their treatment must be clear. Unconfirmed information must not be treated as confirmed input. If the system cannot distinguish the two effectively, pending information should remain in a controlled entry worksheet or staging area. Mandatory fields should not be filled with guesses.

5. Case three: Key information is missing or conflicting, so clarification must come first

Neither the operator nor the agent can resolve the following issues by selecting the value that looks more likely to be correct:

The recap and contract differ on counterparty, buy/sell or grade;
A quantity tolerance is stated, but the option holder is unclear;
The pricing benchmark, differential or currency conflicts across documents;
The pricing period has two possible interpretations;
The payment period or the event that starts it is inconsistent;
Title transfer terms are missing, conflicting, or unclear about which provision takes precedence;
An amendment has been received, but there is insufficient evidence that both parties have accepted it.

The differences can be logged, and the documents and extracted information retained. But disputed fields cannot be confirmed as the official trade terms.

Questions need to go to the appropriate person or team:

Trader: Confirm the commercial terms actually agreed, the intended deal and whether changes are accepted;
Contracts, with Legal where needed: Confirm contract wording, which terms take precedence and the status of amendments;
Finance or Trade Finance: Confirm the operational requirements of the payment arrangements;
Master data or ETRM support: Resolve system mapping issues for business terms that are already clear.

The operator identifies issues, compiles the supporting information, follows up on replies and checks whether the answers provide a sufficient basis for entry. Changes to commercial terms still require the appropriate authority. The operator cannot settle them alone.

6. Repeatedly checking the same trade takes much of the time

In practice, much of the work happens before formal entry.

Operators search different email threads for the recap, contract and proposed changes. They open several PDFs to check figures, dates and terms, then transfer the information field by field into an entry worksheet or the ETRM system. When they find differences, they set out the questions and follow up by email. They then return to the documents to check exactly which issue each reply has resolved.

Errors often occur as information moves between these steps:

Fields copied from an earlier trade retain the wrong port, entity or payment terms;
PDF line breaks or OCR errors cause a minus sign in the differential, a date or a unit to be missed;
An amendment leads to one field being changed without related terms being rechecked;
A reply does not clearly answer the original question, but the issue is marked as resolved;
A search by contract number or filename misses an existing record, and the trade is created twice.

These errors do not necessarily reflect a failure to understand the contract. They can also result from scattered documents, repeated data entry and unclear status records.

7. What an agent can do, and what still requires the operator's judgment

An agent can bring the scattered information together into a set of materials ready for review:

Gather documents: Link recaps, contracts, emails and amendments to the trade. Flag possible duplicates and version changes.
Extract fields: Extract contract information while retaining the original wording, page number or source email.
Compare terms: List differences, missing information and the scope of changes across documents.
Flag related checks: Identify other fields that may need to be rechecked when a term changes.
Prepare draft entries: Map supported information to the ETRM system and keep unresolved items clearly marked.
Prepare requests for confirmation: Set out the conflicting text, questions to be answered, responsible person and deadline. Send routine reminders within the authorised scope.

An agent cannot determine which version applies solely from the document date. Nor can it infer from “noted” that the counterparty has accepted a change. A high extraction confidence score indicates that the text was likely read correctly. It does not establish that the trade terms have been approved.

The operator still needs to assess whether the confirmation evidence is sufficient, whether conflicts have actually been resolved, whether the system mapping reflects the agreement, and whether the record is ready for the next status. Matters requiring commercial or contractual approval must be decided by the appropriate authorised staff.

8. Completion means each field has a basis and each open item has a clear next step

The handover to the next stage should provide a reviewable basis for entry: the current confirmed version, key fields and their sources, outstanding items, required approval records and a clear system status.

Receiving a contract means only that the document has arrived. Readiness for confirmed entry means that the terms required at this stage have been checked, outstanding items have a clear treatment, and the system record can accurately reflect the agreement. An agent can reduce searching, copying and comparison work. It cannot remove the need for that judgment.