Freight Software for Rail and Intermodal Terminal Operators
NVOCCs running private rail ramps live in a different world than container forwarders. You have rail terminal moves, drayage to bulk ag loaders, outbound train release for transpac ocean export, plus the regular NVOCC paperwork on top. A pure freight forwarding TMS does not cover the terminal side. A pure terminal OS does not cover the export side. So most intermodal operators run a stack: CargoWise for the forwarding files, a terminal operating system like Octopi for the ramp moves, an accounting platform like Sage Intacct, and a layer of Excel that holds it all together. This guide walks through why that franken stack happens, what an intermodal NVOCC actually needs from software, how to consolidate rail, drayage and ocean export in one platform, and how to report across the whole operation.
Key Takeaways
- Intermodal NVOCCs commonly stitch together a freight TMS, a terminal operating system and an accounting platform, with Excel filling the gaps between them.
- CargoWise is often "too much system" for a focused rail and ocean export operation; operators typically use only a fraction of the modules they pay for.
- The real workflow runs from empty train build, to drayage to bulk loaders, to outbound train release, to transpac ocean export. Software has to follow the cargo through every step.
- When the terminal, drayage and ocean export sit in one system, accruals stop living in spreadsheets and customer reporting stops being a manual Excel job.
- Right sizing the software stack is the lever. Pick a platform built for ocean and NVOCC workflows, then wire in the rail and accounting integrations you actually use.
Why terminal operators end up on a franken stack
Most intermodal NVOCCs do not set out to run three or four systems in parallel. It happens one decision at a time. A new hire arrives who knows CargoWise, so the company licenses CargoWise for the forwarding files. The terminal needs its own system for gate moves and rail manifest building, so Octopi or a similar terminal OS gets bolted on. Accounting is already in Sage Intacct or QuickBooks. Reporting falls through the cracks, so the finance team builds a master Excel sheet that everybody updates by hand.
An upstate New York NVOCC running 3 private BNSF rail ramps described the result in a sentence:
“We have a lot of systems. They don't all work together. It's all manual. It's all manual.
Logistics Manager, upstate New York NVOCC and rail terminal operator
That franken stack creates four predictable problems for an intermodal operator:
-
1Manual double entry between forwarding and accountingCharges typed in CargoWise also have to be retyped in Sage or QuickBooks. The accrual database ends up living in a large Excel sheet because nothing else has the full picture.
-
2Paying for enterprise features you never touchCargoWise is built for global forwarders running every mode in every country. A rail and ocean export NVOCC will use maybe a quarter of what is licensed. As one operations manager put it, "Cargowise just seems to be like a really big car that we don't need all the functions and features of."
-
3Power user dependencyEvery franken stack has one or two people who hold the keys to the castle. If they leave, the whole operation stalls. The same NVOCC described this directly: "The only reason we ever went with Cargowise is because the person we hired had experience in it. She left about two years ago."
-
4Reporting that requires combining data from multiple placesWhen the terminal data is in one system, financial data is in another, and customer status sits in Excel, "it's much more difficult to pull reporting out and make good business decisions." Weekly customer status meetings end up running off a manually maintained spreadsheet that someone updates by hand each week.
An NVOCC running rail ramps is not a candidate for a stripped down freight broker tool. But it is also not the global enterprise that CargoWise is built for. If you are new to the NVOCC operating model itself, our explainer on what an NVOCC actually is and how it differs from a freight forwarder covers the basics.
What an intermodal NVOCC actually needs
Strip away the enterprise nice to haves and the real software requirements for a rail and ocean export NVOCC come down to a short list.
| Workflow stage | What the software has to do | Why it matters |
|---|---|---|
| Empty train build at the rail ramp | Track inbound empties by car, assign to outbound trains, record gate moves. | If the empty data is wrong, you cannot release a train. |
| Drayage to bulk loaders | Dispatch local drayage moves to ag commodity loaders, capture POD, link the move to the parent shipment. | Drayage cost is a margin line item. It belongs on the same shipment record, not a separate dispatch sheet. |
| Outbound train release | Confirm loaded car list against the train manifest, transmit release to the railroad, file documents. | A miscounted or mismatched manifest delays the whole train. Manual reconciliation is the failure mode. |
| Transpac ocean export | Book vessel space, generate HBL and MBL, file AES, manage carrier and customer documents. | The terminal move only matters if the export shipment goes out clean. |
| Accounting and billing | Generate invoices from the same shipment record, push entries to Sage Intacct or QuickBooks, hold accruals. | If accruals live in Excel, month end always slips. |
| Reporting and customer status | Dashboard per employee or book of business; weekly customer reports pulled from the system, not built by hand. | Customer trust depends on consistent updates. Excel reports break the moment someone forgets to refresh them. |
What is striking is what is not on this list. Air freight is missing. Global customs brokerage is missing. A 17 way menu of features you can access from a dozen places is missing. As one VP of logistics at the same rail NVOCC said, "We don't need a bus."
For a fuller comparison of platforms that fit a focused NVOCC, see our roundup of top NVOCC software solutions, which walks through the trade offs by company size and modal mix.
Consolidating rail, drayage, and ocean in one system
The consolidation play for an intermodal NVOCC is not "rip out everything and start fresh." It is "stop using three systems where one well chosen platform plus targeted integrations would do the job."
- CargoWise for ocean export forwarding
- Terminal OS (Octopi or similar) for rail ramp moves
- Sage Intacct for accounting, populated by hand
- Excel master sheet holding accruals and customer status
- Manual emails to customers with tracking copy pasted from carrier websites
- One shipment record carrying rail, drayage and ocean export
- Drayage dispatched and tracked against the parent shipment
- Accruals booked in the system, accounting pushed to Sage or QuickBooks via integration
- Customer portal and built in tracking, no manual carrier site lookups
- Dashboards by employee or book of business, refreshed automatically
The work breaks into four moves:
-
1Anchor on the ocean export workflowMove the transpac ocean export files first. This is the part of the operation that touches customers, carriers and customs. Get HBL and MBL generation, booking and AES filing running cleanly inside a single ocean export workflow, then layer the terminal moves on top of it.
-
2Pull drayage onto the shipment recordDrayage moves to the bulk ag loaders should sit on the same shipment as the ocean leg. That means one container number, one customer, one set of charges. Cost lines tie to the same record, not to a separate dispatch tool.
-
3Wire accounting through integration, not retypingKeep Sage Intacct or QuickBooks as the book of record, but stop having staff retype invoices. Accounting integrations push entries from the shipment directly into the accounting system on a defined schedule.
-
4Retire the Excel master sheetOnce accruals, drayage cost lines and customer status all live in the platform, the Excel master sheet has no job left. Stop maintaining it. Move the weekly customer report to a saved view or scheduled export from the system.
The Excel master sheet is sticky. Even after the new platform is live, finance teams keep updating the spreadsheet "just in case." Set a hard cutoff date and stop maintaining the sheet on that date. If reporting breaks, you find out which numbers were actually being consumed.
Reporting across the operation
The point of consolidating rail, drayage and ocean export onto one system is not just fewer logins. It is reporting that can answer questions the franken stack cannot.
Questions an intermodal NVOCC needs to answer weekly:
- How many empty cars came in this week, how many loaded trains went out, and which were delayed?
- What is the dwell time at each of our 3 private ramps?
- Per customer, per book of business, how many shipments are open and where are they?
- What is our drayage cost per loaded container, by lane?
- What accruals are sitting unbilled at month end, and against which shipments?
On a franken stack, every one of those reports is a combine and clean job in Excel. On a consolidated platform, they are dashboards. The same rail NVOCC framed the upside as: "Having a dashboard for all your op shipments by whatever employee has their own book of business." That dashboard does not exist when the data lives in three systems.
Consolidation also fixes the customer status problem. Instead of a couple of times a week running an Excel update meeting, the customer sees their shipments through a portal that reads from the same shipment record the operations team works in. No double maintenance, no out of date numbers.
Run your rail ramp moves, drayage and ocean export on one platform built for NVOCCs. See how GoFreight consolidates the franken stack.
Request a GoFreight Demo →FAQ
What is intermodal terminal operator software?
Intermodal terminal operator software is a platform that manages cargo moves at a terminal where rail meets road, road meets ocean, or all three meet. For an NVOCC running private rail ramps, it covers empty car management, train build, gate moves, drayage dispatch and the link from the terminal move to the parent ocean export shipment.
Why do intermodal NVOCCs end up on a franken stack of CargoWise plus a terminal OS plus Excel?
It happens one decision at a time. A new hire knows CargoWise so the company licenses CargoWise. The terminal needs its own software for gate moves so a terminal OS gets added. Accounting is already in Sage Intacct or QuickBooks. Reporting is not covered by any of them, so finance builds an Excel master sheet. None of the systems talk to each other, so staff retype data between them and the spreadsheet holds it all together.
Is CargoWise the right system for a small NVOCC running 3 private rail ramps?
For many focused NVOCCs the answer is no. CargoWise is built for global forwarders running every mode in every country. A US export NVOCC moving ag commodities through private rail ramps will typically use only a fraction of the licensed features while still paying for the rest. The phrase operators use is that CargoWise is "a really big car that we don't need all the functions and features of." A platform sized for ocean export and NVOCC workflows is usually a better fit.
Can GoFreight handle the drayage leg between the rail ramp and the bulk loader?
Yes. Drayage moves sit on the same shipment record as the ocean export leg, with cost lines tied to that record. That means one container number, one customer, one set of charges across the rail, drayage and ocean stages, instead of a separate dispatch tool and a separate Excel reconciliation.
How does software handle outbound train release for transpac ocean export?
The platform tracks loaded cars built at the ramp, reconciles them against the train manifest, generates the export documentation (HBL, MBL, AES) for the onward ocean leg, and keeps the whole sequence on one shipment record. The goal is to remove the manual reconciliation step where a mismatched car count delays the train release.
Does GoFreight integrate with Sage Intacct and QuickBooks?
GoFreight supports accounting integrations so that entries from the shipment record push into your accounting system on a defined schedule. The book of record stays in Sage Intacct or QuickBooks; staff stop retyping invoices between systems. Specific integration details are confirmed during the implementation scoping.
How do we report across rail, drayage and ocean export once we are on one platform?
Reporting moves from manual Excel combining to dashboards built on the live shipment data. You can see open shipments per employee or per book of business, dwell time at each ramp, drayage cost per loaded container by lane, and unbilled accruals at month end, without rebuilding a spreadsheet each week.
What happens to our existing Excel master accrual sheet during migration?
It gets retired. Accruals move into the platform and tie to the shipment record they belong to. Set a hard cutoff date for the spreadsheet and stop maintaining it on that date. If any reporting breaks, you find out which numbers were genuinely being consumed and can rebuild them as saved views or scheduled exports inside the system.
Will my team need a CargoWise level power user to run GoFreight?
No. The franken stack problem of one or two people holding the keys to the castle goes away when the platform is straightforward enough that any operations user can do their daily job in it. New hires get productive faster, and the operation does not stop when a single power user leaves.
