The ETRM Health Check: 25 questions to ask before you blame the software

Every few years someone stands up in a steering committee and says the ETRM is the problem. Sometimes they're right. More often the system is doing exactly what it was configured to do, and the configuration, the data, or the process around it is what's broken.

That difference matters. Replacing an ETRM is expensive and slow, and it doesn't fix bad reference data or an unclear month-end process. You carry those straight into the new system, and three years later someone stands up and blames that one.

Before anyone writes a replacement business case, I run a health check. It's 25 questions in five sections. You don't need a consultant to ask them. You need honest answers from the people who do the work.

How to run it

Ask the questions of the people doing the job, not their managers. A trader, a scheduler, a settlements analyst, a risk analyst, someone from IT. Write the answers down in their words.

Score each question:

• 2: the good answer. It's documented, owned, and repeatable.
• 1: partly there. It works, but it depends on one person or a workaround.
• 0: the red flag.

Five sections, five questions each, 10 points per section, 50 in total.

1. Trade capture

1. How long after execution is a trade in the system, and who enters it?
2. How often are trades amended after entry, and is each amendment reason-coded?
3. Are there deal types you can't book as they really are, so they get booked as a "proxy" of something else?
4. Who owns counterparty, book, and product reference data, and how does a new one get set up?
5. Is there one place to see today's new and amended trades, and does anyone review it?

Good answer: "Same day, booked by the trader or desk assistant. Amendments are rare and coded. Reference data has a named owner and a request process."

Red flag: "We book a placeholder and fix it later." Proxy bookings for structured or non-standard deals are the most common source of downstream breaks I've run into. Everything after trade capture inherits the compromise.

2. Valuation and curves

6. Where do forward curves come from, and who signs off on them each day?
7. Can you explain the day-over-day P&L change by driver: new deals, price moves, time, amendments?
8. How are illiquid points and basis curves built, and is the method written down?
9. Do risk and P&L run on the same trades and the same curves?
10. How long does the end-of-day batch take, and what happens when it fails?

Good answer: documented curve sources with a daily sign-off, a P&L explain that ties out, one set of trades feeding everything.

Red flag: "Risk keeps its own copy of the curves in a spreadsheet." If P&L explain is a month-end exercise instead of a daily report, valuation problems hide until the quarter closes.

3. Operations and scheduling

11. Do scheduled volumes flow from the trades, or are they re-keyed?
12. How do actual volumes come back into the system, and who reconciles them against nominations?
13. Where do schedulers keep their own trackers outside the system, and what are those trackers for?
14. When a counterparty disputes a volume, where does the evidence live?
15. Are confirmations matched against the system's trade record, and who works the breaks?

Good answer: schedules come from trades, actuals are loaded and reconciled on a set routine, and breaks have an owner and an age.

Red flag: a scheduler's personal workbook that everyone relies on and nobody else understands. That workbook is a system. It just isn't backed up, controlled, or tested.

4. Settlement and close

16. How many working days after month-end do invoices go out, and what's the step that gates them?
17. How often are invoices reissued, and what are the top three reasons?
18. Does settlements keep shadow spreadsheets? Who keeps them, and what do they check?
19. Does the subledger reconcile to the general ledger without manual journals?
20. Can you trace a number on an invoice back to the trade, the volume, and the price that produced it?

Good answer: a documented close calendar, reissues that are rare and explained, and full traceability from invoice to trade.

Red flag: "The spreadsheet is just a check." When the check catches errors every month, the spreadsheet has quietly become the book of record.

5. Controls and reporting

21. Who can change a trade after it's confirmed, and is every change logged with a reason?
22. Are segregation-of-duties rules enforced by the system, or only by policy?
23. How are regulatory and compliance reports produced, and how many manual steps sit in that chain?
24. How many customizations do you have, who owns each one, and which ones block the next upgrade?
25. When did you last take a vendor upgrade, and how long did it take?

Good answer: system-enforced permissions, a full audit trail, a customization register with owners, and upgrades on a regular cycle.

Red flag: "We haven't upgraded since go-live because of the customizations." That's not a software problem. It's a decision someone made, one change request at a time.

Reading the score

The total matters less than the pattern. Here's how I read it. These are rules of thumb, not benchmarks.

• Low scores everywhere, worst in trade capture and reference data: this is a process and data problem. A new system will inherit it. Fix ownership first.
• Low in one section, fine elsewhere: this is a targeted fix. Scope a project for that area, not a replacement.
• Low in controls and customization, with upgrades stalled: this is customization debt. Before you replace anything, price out what it would take to get back to a supported, upgradeable version.
• Decent scores, but the business still can't do what it needs to: now you may have a real software gap. Keep reading.

When replacement is actually the answer

Sometimes the software really is the problem. In my experience, replacement is justified when the issue is structural:

• The system can't represent your core deals without proxies, and the vendor has no credible plan to fix that.
• You're on a version the vendor no longer supports, and the customizations make an upgrade cost about as much as a reimplementation.
• The business has changed (new commodities, new markets, environmental products) and the data model can't follow.
• You can't get support, skills, or fixes for the platform anymore.

Even then, do two things before selection starts: give reference data a named owner, and write down how month-end close actually works today. Both carry into any new system, and both make the selection better.

Use it this week

Pick one section. Book 30 minutes with two people who live in it. Ask the five questions and write the answers down word for word. If you only do one section, do trade capture. Most of what goes wrong downstream starts there.

If you run the whole thing, send me the pattern you found (no names, no numbers). I'd like to know which sections score lowest across the industry.

Drafted with AI assistance from my research notes and outline; reviewed, edited, and fact-checked by me. The opinions are mine.