Short Line Railroad Operations Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the switch list get scoped as a data entry screen so often?

Because that is what the office asked for. The visible pain is a clerk retyping a wet piece of paper, so the obvious brief is a faster typing screen. Build that and you have made the transcription quicker without changing the fact that the record is a transcription.

The event and the message have to be the same fact. A car handling event, an interchange, a placement or a release is generated where it happens, on a tablet or a phone in the cab, with the timestamp of the actual move. The industry message is then produced from that record automatically rather than reconstructed later. Two versions of an event, one on paper and one in a system, is precisely the condition that loses you a settlement dispute.

Field capture also looks harder than it is worth until somebody counts the leakage. It is not exotic engineering, it is offline first capture with a switch list a conductor can work from in poor light with gloves on, and local validation so an impossible move is caught before it becomes a rejected message.

The tell in a scoping conversation is a cheap question. Ask the developer to explain constructive placement and how it affects the demurrage clock. It takes two minutes and it tells you whether you are talking to a railroad software team or a general logistics team who will learn on your budget. Follow it with a car set out bad order and later repaired on your property, because that single scenario touches car hire, mechanical, the repair billing files and the interchange report at once.

What goes wrong when you migrate switching agreements and car histories?

Agreement discovery is the schedule risk in this category, and it is almost never in the plan.

Every customer arrangement is different. One pays per car switched with the first two moves free. Another pays a monthly minimum against a per car rate with a volume break. A third has a haulage arrangement at a divisional rate that changes annually. A fourth sits on a track lease with an embedded switching allowance. The industrial park has a reciprocal switch arrangement that applies only to certain commodities. And somewhere there is a paper agreement from years ago whose terms live in the general manager's memory.

Turning that into versioned rate rules is real work involving your general manager and your commercial people rather than the developer, and it takes weeks. It also surfaces disagreements about how a deal has always been interpreted, which is uncomfortable and valuable, because those disagreements are already costing you money.

The second migration problem is the car history itself. Event times in the old system reflect when a clerk keyed rather than when the move occurred, so any analysis built on that history carries the same bias the new system exists to remove. Load it, keep it, and mark it as office keyed so nobody later mistakes it for field captured evidence.

The third is the rate change trap. If your current system edits rates in place, last year's invoices cannot be reproduced, because recalculating them uses today's rate. Rates need effective dates from day one, and if you are migrating history you need to know which rate applied when. Ask what happens to prior invoices when a rate changes, because an answer of edited in place means your historical billing is unreproducible and your first audit will be unpleasant.

Why do interchange messaging and Railinc integrations break after launch?

Because sending is easy and being accepted is not, and most builds only instrument the first half.

Short lines live inside a fixed messaging vocabulary: waybill and shipment information, advance interchange consists, car disposition, car handling events, terminal and ramp activity. The formats are documented and rigid, and equipment characteristics come from the Railinc Umler registry whether you like the data or not. A message can validate perfectly against the format and still be rejected or quietly ignored by the connecting carrier because a car is not where their system thinks it is, or an event sequence is impossible from their point of view.

The design that survives monitors outcomes rather than sends. Every message carries a state: sent, acknowledged, rejected with a reason, or unacknowledged past a threshold. Unacknowledged is the dangerous state and the one most builds do not model, because absence of a rejection looks like success. A system that fires messages and assumes they landed drops events silently, and you find out at settlement, which is the worst time and the weakest position.

The second breakage is asymmetry with the connecting carrier. Their view of your property and yours will diverge, and reconciling monthly is too late. Compare the two views on a regular cycle so a mismatch is found in the same week rather than at settlement when a Class I has already booked their number.

The third is having several connecting carriers. Each relationship has its own reporting expectations and its own settlement quirks, so integration should be priced per carrier rather than as one line.

What happens when car hire, demurrage and constructive placement are not covered?

You run one clock badly and the other not at all.

Car hire accrues against you while a foreign car sits on your property. Demurrage and storage accrue in your favour while a customer holds a car beyond free time. They are the same underlying clock read in two directions, and both depend on precise placement, constructive placement and release times. Prompt and accurate release reporting stops car hire accruing on cars you have already handed back, which is money you keep rather than money you earn, and it is invisible on every report you currently produce.

Constructive placement is the specific killer. The customer's track is full so the car waits on your siding, and whether the clock runs depends on notification and on the terms in your tariff. If the notification was a phone call, you have nothing. Making notification a system event with a timestamp and a delivery record converts an argument into a document, and it is a small piece of software that pays for a meaningful slice of the project.

The second gap is the bad order car. Set out on the house track, it changes car hire liability, opens a mechanical record, eventually flows through the industry repair billing exchange if it is a foreign car you repair, and has to be reflected in the interchange report as being on your property and not moving. Handled manually, that is the most common place a short line loses money in both directions at once, because the same missing record understates what you should bill and overstates what you owe.

Should you build custom or configure what you already own?

License RMI RailConnect and put the money into ties if you are a single property moving under a few thousand cars a year. It is the default for a reason: it handles the industry messaging properly and the connecting carriers know it. Its limit is that the operating model is the vendor's, so when your property does something unusual the change request joins a queue with everyone else's, but at that size the unusual things are few.

Look at Bourque Data Systems if your pain is concentrated in billing and waybilling for a smaller property. It is lean and well regarded on that side, and correspondingly lighter when you also want mechanical, track and crew management in the same system.

PS Technology brings genuine Class I operating pedigree as a Union Pacific subsidiary, and that is exactly the tension. The products reflect big railroad practice and scale down with more process than a three person office wants, so evaluate them against how much administrative overhead your team can absorb rather than against the feature list.

Build at holding company scale, when several properties arrive with different switching agreement structures, transload operations and a car repair shop, and the gaps between the packaged model and each property are absorbed by clerks and spreadsheets. The honest arithmetic is that at that point the annual cost of the workaround, meaning the clerk hours plus the leakage nobody measures, exceeds the build. Start with one property, the waybill and event core and the two clocks, because that is where the recoverable money is and it funds the rest.

How do hidden costs get into the quote?

The number of properties is the first, and whether they share a rate structure. Each property tends to arrive with its own history, its own customers and its own arrangements, so a second property is not a copy of the first.

The number of connecting carriers is the second. Each relationship has its own reporting expectations and settlement quirks, and a quote with one interchange line has priced one carrier.

Third is transload and warehousing, which is a separate inventory business bolted to a railroad. It is not a module of a railroad system, it is a second system that shares customers, and it should be priced as such.

Fourth is mechanical depth, particularly if you bill outside work, because bad order tracking is one thing and producing correct industry repair billing files for foreign cars is another. Fifth is passenger or excursion operations if you run them, which brings ticketing and an entirely different safety and reporting posture. Sixth is agreement discovery, since writing switching agreements, haulage arrangements and track leases down as rules is your general manager's time, takes weeks, and is on the critical path because billing cannot be tested against rules that do not exist yet. It appears in no proposal.

What separates a build that works from one that fails here?

The builds that work are offline first and mean it. Much of a short line's territory has no coverage, so the field application must capture a full shift with no signal, validate locally, and queue synchronisation for when coverage returns. It also needs conflict handling, because the office may have amended a record while the crew was out of contact, and the resolution rule has to be decided by you rather than by whichever write arrives second.

They model rate agreements as versioned rules attached to the customer and the track, with effective dates, so switching, storage, weighing, transloading and every other accessorial lands on the invoice because the event happened rather than because a clerk remembered. That is the mechanism that recovers revenue you have already earned, and it is more valuable than any reporting feature.

They instrument the messaging rather than trusting it, with unacknowledged treated as a failure state, and they reconcile against the connecting carrier's view weekly rather than at settlement.

They give shippers a portal early. Your customers currently phone the office to ask where their cars are, and that call is a person's whole morning. It is a modest piece of software with an immediate and measurable effect on how the office spends its day.

Finally, they settle ownership before kickoff. You should own the repository, the infrastructure accounts and the unrestricted right to appoint another supplier, written into the contract. At Digital Heroes the client owns the code from the first commit. For a railroad this matters more than usual, because the operating record inside the system is also your legal record in a dispute or an investigation, and it should never sit on a supplier's account.