Gas Nomination and Scheduling Software: Why the Cycle Clock Beats Your Spreadsheet Every Month

Why nomination software decides whether you keep your margin

It is 12:40 on a Tuesday afternoon and a scheduler has twenty minutes before the timely cycle closes. She has eleven pipelines to nominate on, each with its own electronic bulletin board and its own login. Her portfolio workbook has a tab per pipeline, a tab for storage, a tab for the supply deals the marketing desk closed this morning, and a tab called BALANCE that she rebuilt by hand yesterday. A producer just texted that a well came back on and there are 3,000 more dekatherms than the workbook assumes. She has to decide, in twenty minutes, where that gas goes, whether it fits under the transport contract's maximum daily quantity, and whether the receipt point operator will confirm it.

The software around that desk is usually Quorum PGAS or ION Openlink for the trading and accounting side, sometimes Energy Solutions International PipelineManager or Latitude Technologies for the operational layer, plus every pipeline's own EBB, plus the workbook. Every one of those tools is real and does something well. None of them holds the object the scheduler actually reasons about: a single position that knows today's supply by point, the transport and storage capacity available to move it, the demand it has to serve, the imbalance already accrued on each pipeline, and the cost of being wrong on each of those.

The cost of the gap is not a mystery, it is on your monthly statements. Imbalance charges and cashout on the wrong side of the market. Penalty exposure when an operational flow order lands and nobody sees it until the next morning. Capacity you paid for and did not use because it was on a tab nobody opened. In the scheduling projects we have delivered, the first thing that shows up when a portfolio finally gets modelled properly is unused firm capacity that had been quietly paid for month after month.

Problem 1: every pipeline is its own system with its own manners

The NAESB standards gave the industry a shared clock. The gas day starts at 9:00 a.m. Central, the timely cycle closes at 1:00 p.m. the day before, evening at 6:00 p.m., and three intraday cycles follow through the flow day. That is the part everyone agrees on. Everything else varies: how a pipeline wants nominations keyed, how it ranks and matches upstream and downstream, whether it supports pathed or pointed nominations, how it publishes confirmations and cuts, what its tariff says about elective imbalance, how its informational postings are structured, and how forgiving its scheduler is at 12:58.

PipelineManager and Latitude both connect to bulletin boards and both do it credibly. What they cannot do is encode the specific negotiated behaviour of your relationship with each pipeline, and they will not tell you that a particular pipeline's confirmation pattern means you should submit early on Fridays. That knowledge sits with the scheduler who has done it for nine years.

What a custom build does: a connector layer per pipeline with an explicit behaviour profile, so submission, confirmation retrieval and posting parsing are all configuration around one internal nomination object. Where a pipeline supports EDI or an API, you use it. Where it does not, you automate the portal and treat that connector as maintenance you have budgeted for, because portals change. The important part is not the plumbing. It is that a nomination exists once in your system and gets expressed eleven ways, rather than being retyped eleven times.

Problem 2: your portfolio constraints are yours, and nobody models them

Your transport contracts have maximum daily quantities, fuel and lost-and-unaccounted-for retention percentages, receipt and delivery point rights, and in some cases seasonal or ratcheted terms. Your storage has injection and withdrawal ratchets tied to inventory level. Your supply deals have index pricing, minimum takes, and operator behaviour that is nothing like the contract. Your demand has weather sensitivity and a couple of customers who call.

Generic scheduling tools represent contracts as a capacity number and a point list. That is enough to submit a nomination and not nearly enough to decide the right one. The scheduler compensates by holding the real constraint set in her head and using the tool as a typing interface. Which is why the tool never gets credit for anything and never gets replaced.

What a custom build does: model contracts as constraints, then let the system propose the nomination set. Given today's expected supply, demand, storage position, and each pipeline's current imbalance, produce the allocation that meets demand at least cost including the imbalance and fuel consequences, and show the scheduler why. This is a routine optimisation problem, not research. The output is a proposed nomination per pipeline that a human reviews and adjusts in five minutes rather than assembles in fifty. On an intraday cycle when a well comes back on, five minutes versus fifty is the whole difference between capturing the gas and eating an imbalance.

Problem 3: confirmations and cuts arrive after you stopped watching

You nominate. Then the pipeline confirms with the upstream and downstream operators, and what gets scheduled may be less than what you asked for. A cut on one pipeline means your supply and demand no longer balance, and the fix has to happen in the next cycle. If nobody is watching bulletin boards between cycles, you find out from the invoice.

This is where spreadsheets fail hardest, because a spreadsheet cannot poll. The scheduler either sits refreshing portals or accepts the risk. Most accept the risk, and the risk is priced into the cashout you pay every month without ever quite deciding to.

What a custom build does: poll confirmations and scheduled quantities continuously, compare them against what you nominated, and raise an exception the moment they diverge by more than a threshold you set. The same watcher reads operational flow orders and critical notices off the informational postings so an OFO on a pipeline you are not actively working still reaches a human within minutes. Alerting has to route by severity and time of day, because a cut of 200 dekatherms at 3:00 p.m. is an email and an OFO at 2:00 a.m. is a phone call. Getting that routing right is a real design conversation and it is the feature schedulers thank you for.

Problem 4: imbalance is discovered at month end, when it is already expensive

Every pipeline has its own tolerance band, its own cashout formula, and its own trading window for resolving imbalance with other shippers. Some let you park and loan. Some price cashout punitively outside a narrow band. The shipper who tracks imbalance daily can trade or park out of trouble. The shipper who finds out on the statement pays whatever the tariff says.

Gas accounting systems calculate imbalance accurately, after allocation, after the month closes. That is the correct time for accounting and the wrong time for operations. There is no packaged product that gives an operational scheduler a live estimated imbalance per pipeline that is good enough to act on, because building it requires your allocation assumptions and your measurement feed.

What a custom build does: maintain a running estimated imbalance per contract per pipeline using scheduled quantities against measured actuals as they arrive from your measurement system, with an explicit confidence indicator so nobody treats an estimate as a settled number. When a pipeline's estimate approaches its tolerance band, the system flags it while there are still cycles left to fix it. Then at month end, the reconciliation between your estimate and the pipeline's statement becomes a short review rather than an investigation, and disputes are raised inside the tariff window instead of after it closes.

Problem 5: nobody can reconstruct why you nominated what you nominated

A pipeline disputes a scheduled quantity. A regulator or an internal auditor asks how a particular day was scheduled. A trader claims the desk failed to move gas it had bought. The evidence is a workbook that has been overwritten 400 times and a scheduler's memory.

What a custom build does: store every nomination as an immutable submission with the portfolio state it was computed from, the constraints active at the time, the confirmation received, and any manual override with the person and the reason. Reconstructing a day means opening it, not reassembling it. This costs almost nothing to build if it is designed in from the start and is close to impossible to retrofit, which is why it belongs in the first release.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the shape for this category. A focused first release covering a proper portfolio and contract model, cycle-aware nomination assembly with a suggested allocation, automated submission to your highest-volume pipelines, and confirmation capture with exception alerting runs $80,000 to $160,000 and ships in 14 to 20 weeks. A full platform adding live imbalance tracking, park and loan and cashout modelling, OFO and critical notice monitoring, storage ratchet handling, and month-end reconciliation against pipeline statements runs $200,000 to $500,000 phased over 8 to 14 months.

What drives cost up: the number of pipelines, because each connector is real work and portal-based ones need ongoing maintenance. Storage with ratcheted injection and withdrawal rights, which is genuinely fiddly to model correctly. Capacity release and asset management agreements, which change who is nominating on whose behalf. Intrastate pipelines and LDC citygate arrangements that do not follow the NAESB conventions cleanly. And any requirement to write back into an existing gas accounting system rather than own both ends.

What keeps cost down: start with the four or five pipelines that carry most of your volume and the contract types you actually use. The long tail can stay manual for a while and it will cost you almost nothing to leave it there.

Build versus buy, and when buying is right

Buy, or rather stay where you are, if you nominate on one or two pipelines under firm transport with stable supply and demand. The pipelines' own bulletin boards and a well-kept workbook are adequate, and a build would be an expensive way to formalise something that already works. The packaged operational tools are also a fair fit if your portfolio is genuinely conventional: firm transport, no storage optimisation, no marketing desk changing positions intraday.

Build when two or more of these are true. You nominate across more than about six pipelines. Your portfolio includes storage you actively optimise rather than just fill and drain. Your marketing desk changes positions inside the flow day and the scheduler learns about it by text message. Imbalance cashout has become a predictable monthly cost you have stopped questioning. Or the entire scheduling function depends on one person who cannot take a week off in winter.

Our position: nomination is not data entry, it is a daily optimisation under a hard deadline with real money on both sides of every decision. Once the portfolio is complex enough that a human cannot hold it, the choice is between a system that reasons about your constraints and a scheduler who guesses well most of the time. Guessing well most of the time is not a strategy you can staff.

How to choose a developer for gas scheduling software

Ask them to draw your contract model before anything else. If they draw pipelines and volumes, they will build a submission form. If they draw contracts with capacity rights, points, fuel retention, and constraints that vary by day, they understand what a scheduler actually decides.

Ask what happens when a pipeline changes its portal. The honest answer is that it breaks and someone fixes it within a day, and they should have a monitoring and alerting plan for exactly that. Anyone promising it will never break has not maintained a portal integration.

Ask how they will represent an estimated imbalance and how they will stop people treating an estimate as settled. Confidence indicators and clear labelling are a design decision, and a team that has not thought about it will ship a number that gets someone in trouble.

Ask who owns the code, the connectors, and the credentials, and get it in the contract before kickoff. You should own the repository and the infrastructure accounts and be free to hire anyone else. At Digital Heroes the client owns everything from the first commit.

The practical starting point is to sit a developer next to your scheduler for one full timely cycle, including the part where she overrides her own plan. If they cannot describe your portfolio constraints back to you afterwards, they are not the right team.