Fixture Management Software: What Shipbrokers Should Evaluate

Shortlist :: Select a cargo-vessel opportunity worth commercial follow-up. Negotiation :: Record offers, counters, owners and key terms without losing sequence. Subjects :: Track outstanding conditions, responsible parties and expiry or lifting status. Approvals :: Capture required internal or external decisions with timestamps. Recap :: Build and version the agreed commercial summary. Documents :: Keep supporting files and references tied to the correct fixture version.

Handoff :: Pass the final record to operations, accounting and contract workflows.

Object | Important fields | Control requirement

Opportunity | Cargo, vessel, route, dates, counterparties and source | Preserve the pre-fixture context

Negotiation event | Offer or counter, sender, owner and time | Keep chronological history

Term | Name, value, unit, source and status | Show changed and unresolved terms

Subject | Description, owner, deadline and state | Distinguish outstanding, lifted and failed

Approval | Decision, approver, timestamp and note | Prevent silent or ambiguous approval

Recap version | Terms, author, created time and status | Identify draft, superseded and final versions

Audit event | Actor, action, object and time | Make critical changes reviewable

Version history :: Prior recap and term versions remain recoverable and clearly superseded. Permissions :: Users see and change only the fixtures, rates and documents appropriate to their role. Reminders :: Subjects, approvals and handoffs have owners and visible due states. Templates :: Recap structures can be governed without hiding changes to clauses or values. Search :: Users can find a fixture by counterparty, vessel, cargo, route, dates or reference.

Export and handoff :: Final data moves into accepted operational formats with a clear status. Security :: Authentication, session controls, encryption and audit responsibilities are documented.

Email-only recap editing creates risk when several attachments or copied text blocks circulate at once. A suitable system identifies the current draft, records who changed a term, compares revisions and marks the final approved version. Structured terms must not remove the original commercial context. The workflow should make missing values and unresolved subjects explicit rather than presenting an incomplete recap as final.

Conflicting versions can send different instructions to operations and counterparties. Missing approvals can make responsibility unclear. An email-only history may be complete but difficult to reconstruct under time pressure. Unclear ownership allows subjects to expire without action. Weak permissions expose sensitive rates. Poor handoff loses the source, assumptions or latest terms that the next team needs. Evaluation should test these failure cases directly.

Capability | Pre-fixture matching | Fixture management | LaycanMatch position

Parse offers | Core input | May import context | Supported where fields are present

Rank cargo-vessel fit | Core | Not the primary purpose | Supported shortlist workflow

Negotiation log | Outside basic matching | Core | Not claimed

Subjects and approvals | Outside basic matching | Core | Not claimed

Recap version history | Outside basic matching | Core | Not claimed

Document handoff | Selected exports or source context | Core operational control | Describe only actual export and email actions

A useful handoff from matching includes the selected cargo and vessel records, route and laycan context, size or DWT, broker identity, received and processed timestamps, confidence and source message. The fixture system should retain or reference this context while adding negotiation, subjects, approvals and recap versions. Re-keying should not erase uncertainty or convert an extracted field into an agreed term without review.

• See pre-fixture cargo-vessel matching

This guide is an operational software-evaluation resource and does not provide legal advice about recaps, charter parties, authority or contract formation. Organizations should obtain qualified legal and commercial guidance for their agreements. LaycanMatch does not claim to manage fixture records, approvals, subjects or charter-party documents.

A fixture workflow should identify the current recap version, unresolved subjects, responsible person and approval status. Test a case where several terms change in quick succession and confirm that users can distinguish proposed, agreed and superseded wording. Permissions should prevent unauthorized approval while still allowing relevant participants to review. Notifications should point to the exact item requiring action instead of sending an ambiguous general alert.

The final record should show the evidence used for each approval without implying that software replaced legal or commercial judgment.

Confirm which emails, attachments, chat messages and uploaded documents become part of the fixture record. Test duplicate attachments, renamed files, forwarded chains and a document received after approval. The system should make inclusion rules visible and preserve the original artifact where required. Ask how retention, deletion, export and legal hold are handled.

If email is connected, verify whether the product reads selected folders, sends messages, or only stores references; these are materially different security and operational models.

A completed recap usually hands data to operations, documentation, accounting or another chartering system. Map the fields required by each team and identify who verifies them before transfer. Test vessel and counterparty identifiers, cargo quantity and tolerance, ports, laycan, freight, commissions, demurrage terms and special clauses. Confirm how later amendments are represented.

A good workflow prevents an old version from being mistaken for the current agreement and makes the source of each changed value available for review.

LaycanMatch works upstream of recap and fixture control. It parses supported fields from incoming broker emails, keeps source context, provides searchable offers and ranks cargo-vessel candidates. Once users select a commercial opportunity and negotiation begins, a dedicated fixture-management process should control terms, approvals and documents. Evaluate the handoff explicitly: which structured fields can be exported, what must be rechecked and how the team avoids treating an extracted offer as an agreed fixture.

Begin with an identified opportunity and create a controlled negotiation record only when commercial follow-up starts. Capture each offer and counter in chronological order with sender, recipient, owner and timestamp. Separate agreed terms from proposals and keep outstanding subjects visible. Record the authority and evidence for approvals. Build the recap from the current agreed terms, version it when wording changes, then mark one version final according to the team’s process.

Handoff should transfer the final version and required data to operations, documentation and finance while preserving the pre-fixture source context and later amendments.

State | Entry condition | Required control before transition

Opportunity | Cargo-vessel candidate selected for contact | Source records and reviewer identified

Negotiating | Offer or counter exchanged | Chronological event and current term set recorded

On subjects | Commercial terms provisionally agreed with conditions outstanding | Subject owner, deadline and status visible

Approved | Required internal or external approvals recorded | Approver, time, decision and version identified

Recap draft | Current terms assembled for review | Unresolved wording and superseded versions visible

Recap final | Authorized final version designated | Version reference and approval evidence locked or controlled

Handed over | Operations and downstream teams receive approved information | Recipient, time, amendment process and document set recorded

Failed or withdrawn | Negotiation ends without fixture | Reason and last valid state retained according to policy

Use a dry-bulk case with one cargo, one vessel, two counterparties, a quantity range, two laycan alternatives, freight, commission and demurrage wording. Enter an initial offer, two counters and three subjects with different owners and deadlines. Create a recap draft, revise one commercial term, add an attachment and request approval.

The resulting record should identify the current terms, unresolved subjects, latest recap, prior wording, supporting communications and authorized approver without forcing users to reconstruct the sequence from an email chain.

An offer or counter records a commercial proposal at a point in time. A subject records a condition that must be satisfied or lifted, often by a deadline and a named party. Treating both as free-form notes makes it difficult to know what is current. Test whether the system preserves every counter, links changed terms to the correct event and displays subject state independently.

A lifted subject should retain who changed it and when; an expired or failed subject should not disappear merely because negotiation moved on.

Alerts should name the exact fixture, subject, approval or document requiring action and link directly to it. Users need configurable reminders before deadlines, clear overdue status and an escalation path that respects permissions. Test timezone handling and repeated notifications so a reminder does not become noise. A notification confirms that the system raised an event; it does not prove that a counterparty received or accepted a commercial message unless that delivery evidence is separately available.

Define roles for viewing sensitive rates and commissions, editing terms, lifting subjects, approving recap versions, exporting records and deleting data. Documents need type, owner, version, received time and relationship to the current fixture state. Test renamed duplicates, a corrected attachment and a file linked to the wrong recap.

The system should distinguish draft, superseded and final artifacts and prevent a user without authority from changing final status, while still preserving a reviewable record of permitted amendments.

Email preserves communication but does not automatically identify the current term set, final recap or owner of an outstanding subject. Forwarded chains can omit attachments, copied recipients may work from different versions, and searching by vessel or counterparty may return several conflicting drafts. Deadlines remain in individual inboxes, while operations may receive a recap that was later amended.

A fixture system should reduce these reconstruction risks without pretending that storing every email alone creates an accurate operational record.

Map :: Document the current offer, subject, approval, recap and handoff process. Configure :: Define states, roles, templates, deadlines and retention without hiding exceptions. Test :: Run a representative fixture with changed terms, failed subjects, duplicate documents and restricted users. Reproduce :: Ask a second user to identify the current recap and explain every transition. Export :: Verify the operational handoff and amendment reference.

Govern :: Record accepted gaps, owners, review frequency and rollback approach before wider adoption.

Use a hypothetical negotiation in which quantity, laycan, freight and demurrage wording change across several emails. Create an initial recap, mark unresolved subjects and assign owners. Apply one amendment while preserving the superseded wording. Add a late document and verify that it does not silently become part of the approved record. Ask one user without approval rights to attempt finalization.

The system should keep a clear current version, show remaining subjects and record who approved which version and when.

Test case | Expected behavior | Failure signal

Changed term | New version with visible comparison | Prior wording disappears

Open subject | Clear owner and unresolved status | Fixture appears final

Duplicate document | Detect or clearly label both copies | Ambiguous attachment list

Unauthorized approval | Block and record the attempt where appropriate | Any user can finalize

Late amendment | Link to the current record and preserve history | Separate untraceable file

Operations handoff | Transfer approved fields with version reference | Old recap used downstream

Define who can create, edit, approve, export and delete fixture records. Ask whether sensitive freight, commission and counterparty data can be restricted. Confirm how long emails and documents remain available, whether retention differs by plan, how account closure is handled and what exports are available. Review change history for terms, approvals and attachments. An audit trail is useful only when users understand what events it captures and when administrators can alter or remove data.

Pilot representative fixtures across simple and complex routes, several counterparties and different document sets. Map the current recap, approval and operations handoff before configuring software. Measure duplicate entry, version confusion and time spent finding the current term rather than assuming automation will solve an undefined process. Train users on status definitions and amendment rules.

Review the pilot with chartering, operations, documentation, finance, legal and security stakeholders before expanding the workflow.

Before importing historical fixtures, define which records are authoritative and which files are duplicates, drafts or incomplete. Choose a cutoff date and decide whether older records remain read-only. Normalize vessel, counterparty, port and cargo identifiers only where the team can verify them. Preserve original references so migrated terms can be checked. Test import with a small batch, reconcile counts and sample individual records before moving the remaining history.

Plan how users will find an old fixture, distinguish it from an active negotiation and report a migration error without editing the source silently. Include security, operations and legal owners in the migration sign-off, and retain a rollback copy until the imported records and attachments have been reconciled.