Confidential Proposal
Sullivan Shipping Agencies Ltd
Enter the access password to continue.
Enter the access password to continue.
Neural AI has completed a full discovery session across Sullivan Shipping's four operational departments. This document sets out exactly what we will build, for whom, and how — turning manual, email-heavy workflows into structured, AI-assisted operations backed by Microsoft 365 and SharePoint.
Four proposal streams, one operating principle: AI drafts, humans decide. Every external email, every document, every batch file goes out only after a Sullivan employee reviews and approves it.
This proposal is backed by a consortium of three specialist companies — Neural AI, Born Digital, and Veracloud — operating under the Born Group umbrella with combined revenue exceeding €10 million and over 130 people across 4 offices.
Malta-based AI engineering firm. Designing, building, and owning the AI copilots, automation pipelines, and integrations end-to-end. The team responsible for every stream in this proposal.
Full-service digital agency and parent of the Born Group. Serving enterprise clients across Malta and the Mediterranean including government agencies, banks, and leading brands since 2008.
Certified Microsoft Partner of the Year 2025 and ISO 27001 accredited. Specialists in Microsoft 365 deployment, SharePoint configuration, and enterprise security — responsible for the cloud infrastructure underpinning every stream.
The Born Group consortium has delivered digital transformation for Malta's most recognised institutions, banks, and brands.
Across four departments, the same pattern repeats: skilled operators spending hours on repetitive, email-driven administration that AI can handle — without removing human judgment from the decisions that matter.
Logistics handles the full document lifecycle for every voyage — from the first booking email through to customs clearance. Layered on top of that is a statutory obligation: NSO Intrastat reporting for every EU-origin import, every period. Both workflows today are manual, repetitive, and email-driven. Two AI streams address them.
A new booking email lands in the Logistics shared mailbox. Power Automate detects it and creates a SharePoint job folder named by voyage reference and date. The job record is populated with all fields extractable from the booking email: shipper, consignee, vessel, port of loading, port of discharge, and cargo description. The operator sees the new job immediately — no manual folder creation.
Over the following hours and days, the voyage documents arrive by email: Bill of Lading (or House Bill of Lading), commercial invoice, packing list, T2L, MRN, and Notice of Arrival. Each document is automatically attached to the SharePoint job folder as it arrives and timestamped. The copilot tracks which documents are present and which are still outstanding, surfacing a live completeness status on the job record.
Once all expected documents are in the folder — or the operator marks the job ready — the copilot runs a structured cross-check. Every key field is verified for consistency across all documents simultaneously:
Consignee name: consistent across BL, invoice, and NOA? · Cargo description: consistent across BL, invoice, and packing list? · Quantities and weights: do packing list figures match the invoice and BL? · HS code: present on invoice or packing list for NSO? · T2L reference: present and correctly linked to the MRN? · Port of loading / port of discharge: consistent across all documents?
The copilot produces a Validation Document in SharePoint — a structured pass/fail grid. Green = field consistent across all sources. Red = discrepancy detected, with a note explaining what differs and where. Amber = field present in some documents but missing in others. The grid is attached to the job record and visible to the operator without opening individual files.
For every red or amber field, the copilot drafts a chase email to the relevant counterparty — carrier, shipper, or agent — identifying the specific discrepancy and requesting a correction or the missing document. The operator reviews the draft and sends. Nothing goes out automatically. The corrected document, once received, is attached to the same job folder and the validation re-runs.
For every completed voyage in the Logistics job record, the copilot checks whether NSO Intrastat reporting is required. Only EU-origin imports require an Intrastat declaration. Non-EU imports, exports, and transshipments are automatically excluded. The eligibility decision is rule-based and transparent — it is shown on the job record so the operator can verify it.
For each eligible line, the copilot calculates the statistical value per the NSO Malta formula: supplier invoice value (CIF or FOB as declared on the commercial invoice) plus apportioned freight cost to the Malta border where the invoice is FOB. Freight is apportioned across all shipment lines by weight or value, matching whichever basis the freight invoice uses. Each calculation is shown with its source figures so the operator can check the arithmetic.
Lines are grouped by HS commodity code and country of origin (COO) — the two dimensions NSO requires for each Intrastat entry. Where multiple shipment lines share the same HS code and COO, their statistical values are summed into a single declaration row. Any line where the HS code is missing or the COO is ambiguous is automatically separated out into the Exception Report (step 5) rather than being guessed.
The copilot generates an XML file in the exact schema published by NSO Malta — confirmed with Maria Cortis at NSO Malta in May 2026, who confirmed that XML upload is the recommended format for high-volume submissions. The XML is validated against the schema before it is presented to the operator. Schema validation errors are shown with the field name and expected format, not just a raw error code.
The copilot produces an Exception Report alongside the XML: every shipment line that could not be included due to a missing HS code, unclear country of origin, or zero-freight value. The operator resolves each exception — confirming the HS code from the invoice, correcting the COO, or noting the freight basis — then the affected lines are re-processed and added to the XML. The operator uploads the validated XML to the NSO portal. NSO has no API; the upload is a manual step. The copilot does not submit on the operator's behalf.
Accounts sits at both ends of the cash cycle: sending receipts to clients when money comes in, and assembling payment batches for Bank of Valletta when money goes out. Both flows today are manual and repetitive. The AI handles the rhythm; Finance retains control of every decision that matters — especially disputed invoices.
The accounting system records a matched payment against a client invoice. This match event is the trigger for the Auto-Receipts Engine. The engine receives the payment reference, client name, amount, and date — it does not need to be manually started or monitored.
The engine looks up the paying client in Sullivan's master email list — the file Sullivan already maintains. If the client has an email on file, the receipt process proceeds. If no email is found, the payment is added to an Exception List in SharePoint and Accounts is notified to handle it manually. The engine never silently drops an unmatchable payment or sends to a guessed address.
The engine generates a branded receipt email (Sullivan logo, address, ISO 9001 footer) and sends it from a dedicated finance address — receipts@sullivanshipping.com.mt. An optional PDF receipt is attached. Every send is logged against the payment record: timestamp, client, payment reference, and amount. The log is the audit trail. If a payment is later reversed or disputed, the send-log makes it immediately clear which client received a receipt and when.
Suppliers send their statements to statements@sullivanshipping.com.mt. Statements arrive as PDFs, Excel files, or scanned images — any format, any layout. The AI listener detects each arriving email, identifies it as a supplier statement, and resolves the sender against the Supplier Master.
The AI extracts every line item from the statement regardless of format: invoice number, invoice date, due date, amount, currency, VAT reference, and PO number where present. The Supplier Master holds the canonical supplier name, statement sender email(s), agreed credit terms in days, BOV IBAN, and payment cycle preference (2-week or 4-week). The AI uses these fields; it does not guess them.
For each extracted line, the system applies a simple, explicit rule: is today's date ≥ invoice date + this supplier's credit days? If yes, the line is eligible for the current payment batch. If not, it is deferred to the next cycle. This logic lives in the Supplier Master as a plain number — 30 days, 45 days, 60 days. It is not inferred by AI; it is the agreed contractual term entered by Finance.
Finance can flag any invoice line as disputed at any time via the Dispute interface — a searchable list of all open supplier statement lines. Each disputed line requires a free-text reason and records who flagged it and when. Disputed lines are excluded from every BOV batch until they are explicitly resolved by Finance. There is no AI override of a dispute. The interface also shows an at-a-glance total of disputed amounts per supplier so disputes do not quietly accumulate.
At the close of each payment cycle, the system assembles a single BOV batch file containing all eligible, non-disputed lines across every supplier. The file is generated in the exact format required by Bank of Valletta — CSV, XML, or fixed-width, confirmed at kick-off. Every line in the batch is linked back to its source statement and credit-term setting.
Finance receives the batch file for review. The review screen shows the full line-level breakdown — supplier, invoice, amount, credit-term basis. Finance verifies, approves, and uploads to BOV. The AI never touches the bank session. The upload is always a human action.
Once the batch is uploaded, Finance marks the run as complete. All lines in the batch are flagged as paid in the system and excluded from all future cycle calculations automatically. The cycle resets and the next set of statement arrivals begins building the following batch.
Agency is a 24/7 on-call function coordinating between ships and Sullivan's supplier network. Three specific workflows drive most of the administrative load: the daily PPG fuel barge schedule that arrives as an Excel and is pivoted by hand; the quoting and vessel-call calendar that today lives in an Excel with App Scripts; and the Charge Sheet that must be assembled from supplier invoices after every vessel call. Three streams, one connected system.
Every day, PPG (Penancy Petroleum) emails the barge schedule as an Excel attachment. Power Automate detects the arrival by matching the sender address, subject pattern, and attachment type. No manual monitoring is needed.
The attachment is uploaded to a SharePoint document library — one folder per month, files named yyyymmdd_PPG.xlsx. The copilot normalises the sheet to a consistent column structure regardless of any formatting changes PPG makes to their source file over time. The normalised version is what gets stored and appended; the original is retained for reference.
The normalised day's rows are appended to the Monthly Master sheet in SharePoint. The Master accumulates every day for the month automatically. There is no end-of-month data-wrangling step — by the time the last day of the month arrives, the Master is already complete.
A pivot table on the Monthly Master refreshes automatically after each append. The Agency team sees a live month-at-a-glance view at all times. The SharePoint index makes the full history searchable: answering "where was the barge on the 12th?" takes seconds, not a trip through a folder of archived Excels.
The existing Agency quote calculator is rebuilt as a clean, web-based tool (Power Apps + SharePoint, or Replit — confirmed at kick-off). Every pricing rule, surcharge, currency conversion rule, and discount logic from the current calculator is extracted, documented, and re-implemented as a testable function. The operator fills in the vessel call details; the calculator applies the rules and produces a structured quote: parties, vessel name, services agreed, line items, totals, validity period.
The operator reviews the generated quote and approves it with one click. The record is locked and version-tagged. The approved quote becomes the reference point for the charge sheet later. If the quote needs to change after approval, a new version is created — the original is never overwritten.
On approval, the vessel call is automatically created as an entry in the Agency Calendar in SharePoint / M365 — vessel name, ETA, services agreed, supplier bookings, and a link to the approved quote. This replaces the current Excel + App Script calendar. Multiple operators can view and update the same calendar simultaneously with full change history.
The copilot drafts the documents that flow between Sullivan, the ship, and Transport Malta's submission system. The operator reviews each document and sends — no autonomous external sends. Where Transport Malta has an accessible portal, the copilot pre-fills the submission fields from the calendar entry; the operator completes and submits.
When the operator updates a date on the calendar entry — weather delay, customer change, port congestion — the copilot immediately drafts notifications to the affected parties: the ship, affected suppliers, and optionally the client. Each notification draft is reviewed and sent by the operator. Nothing goes out automatically. The calendar entry records the change and reason, maintaining a full history of date movements for any post-voyage review.
As the vessel call is completed, supplier invoices arrive by email — fuel barge, chandler, repair yard, port-service providers. The copilot identifies each invoice against an open job by cross-referencing the vessel name, service date, and any reference number present in the email. The invoice is attached to the SharePoint job folder and a matching entry is created in the draft Charge Sheet for that job.
From each invoice — PDF, Excel, or any format — the copilot extracts line items and amounts. Each extracted line is added to the draft Charge Sheet, building it incrementally as invoices arrive. The operator can see the Charge Sheet growing in real time, without having to open individual files or copy-paste numbers.
When the operator declares the job closed — or when all expected suppliers have invoiced — the copilot produces the final Charge Sheet. It shows the actuals side-by-side against the original approved quote from Stream B. Deltas are highlighted: services added, hours over estimate, missed line items, currency differences. This comparison is itself a margin-management tool — over time it reveals systematic differences between what gets quoted and what gets spent.
The operator reviews the Charge Sheet, notes or adjusts any discrepancies, and approves it. The approved Charge Sheet is delivered to Finance / billing so the final client invoice can be raised. This handoff connects directly to the Accounts pipeline — the charge sheet is the source document for the client invoice, and both teams see the same record.
Road Operations runs Sullivan's Italy ↔ Malta and Europe ↔ Malta groupage and FTL service. The team — Aleksandar Jovanovic and Aaron Attard — receives bookings from Sales, coordinates with warehouses and trucking agents, issues Transport Orders and Routing Orders, and monitors shipments through to delivery. Two streams: an AI copilot for the Transport Order workflow, and a Replit-built internal tool to replace the trailer-rate Excel files.
A new booking email lands in the Road Ops mailbox from Sales (Jennifer Carabott or Cristina Rusu). The copilot classifies this as a NEW BOOKING and creates a SharePoint job record. It extracts every field it can find: client name, supplier or warehouse name, cargo details (pallets, cbm, weight), loading references, agreed rate, country of loading, and ETA where stated. Missing fields are flagged immediately on the job record — not buried in an email thread.
The copilot checks the country of loading against the Road Ops ownership table — a simple lookup maintained by Sullivan that maps each trade lane to a named owner. Italy-and-beyond lanes go to Aleks; other country lanes go to Aaron. The job is tagged with the assigned owner and they are notified. Sullivan controls the ownership table and can update it at any time without a code change.
The country of loading determines which execution path the job follows. This is the most important fork in the Road Ops workflow:
When the warehouse replies with loading instructions — for example, Dachser Netherlands BV (Waddinxveen) replying with Cargoclix booking requirements — the copilot parses the email and appends these constraints directly onto the Transport Order draft. Rules like "trucks > 3.5t only", "sealed pallets cannot be dismantled", "truck plate number required in the Cargoclix booking", and "loading only at designated docks" are pulled out of the email and written into the document automatically. They are never lost between the email thread and the Transport Order.
The copilot prepares a draft email for every outbound communication the operator needs to send: to the carrier with the confirmed price, loading references, and Transport Order attached; to the Italian warehouse partner with onward instructions and the second Transport Order attached; and to the Cargoclix slot-booking system (or a draft booking instruction if the API is not available — confirmed at kick-off). The operator reviews every draft and sends. Nothing goes out without operator approval.
When delays, slot changes, or customer queries arrive during transit, the copilot drafts factual status updates for operator review. Status updates always speak in observed facts: "Trailer loaded at Waddinxveen on 12 May 2026 at 16:30. Cargoclix booking 02318690 confirmed. Onward leg via E. van Wijk." They never contain promises — no "will arrive by", no "guaranteed delivery". If an exception occurs (no-show, failed collection, capacity issue, complaint), the job is immediately escalated to the operator with no AI-drafted response attempted.
This is a separate, non-AI workstream: a small internal web application built in Replit that retires two current Excel files. It is not an AI tool — it is a structured database with a clean UI and an API that the Road Ops Copilot reads from.
Microsoft 365 is the backbone — Power Automate for orchestration, SharePoint for data and documents, Microsoft Copilot for language intelligence. Replit for the internal Trailer Rates tool. Claude AI for document extraction where needed.
Sullivan holds ISO 9001 certification. Every element of this proposal is designed to support that posture — full traceability, human approval at every external action, and no AI making irreversible decisions.
Six deliverables. Two pricing options. One rule throughout: while your team is being trained on what we just built, we are already building the next item. No idle time between phases.
Same quality, same team, same parallel training model — spread over a longer engagement. Each 1-month deliverable becomes 2 months; the 1.5-month deliverables become 3 months. Suitable if internal capacity for change management is limited.
Full team, full pace. Your team is operational on each deliverable before the next one is complete, maximising time-to-value. The parallel training model means there is no waiting period between phases.
Indicative pricing is included in the Roadmap section above. A formal commercial document with payment schedule and contract terms follows separately.
The discovery is done. The proposal is in your hands. The next step is a kick-off call to confirm assumptions, agree on sequencing, and get started.