Grid-forming mandates turn inverter specs into financial risk clauses

“Grid-forming mandatory” sounds like a technical footnote. It is not. It is a reallocation of responsibility.

When a regulator makes grid-forming inverters required for large-scale storage, as Portugal is now doing while launching a 1GW tender and leaning on BESS to strengthen reliability, the inverter stops being a box that follows the grid and becomes part of the grid’s stability story itself (Portugal makes grid-forming mandatory for large-scale BESS and launches 1GW tender).

That one sentence changes four things at once:

• What you must specify (not just performance, but behaviour under stress).
• What you must prove (not just at FAT/SAT, but as an evidence chain that survives audits and claims).
• What “grid-code compliant” actually means in procurement language.
• Who carries the economic downside when the grid asks for stability instead of revenue.

If you treat these as separate workstreams, you will ship a compliant plant that is commercially fragile. You will “pass” and still lose money.

1) The practical shift: from capacity product to behaviour product

Most projects still buy an inverter like it is a capacity machine: MW in, MW out, hit a few power factor points, show a response curve, sign off, move on.

A grid-forming mandate forces a different mental model. The grid is effectively saying: “Your BESS is now part of my stabilising equipment.” That is a behaviour contract.

So the spec cannot stop at nameplate ratings. It has to describe how the plant behaves when the system is ugly:

• Voltage and frequency formation: not only droop settings, but how droop transitions, saturates, and recovers.
• Fault ride-through with intent: staying connected is not enough if the control mode becomes unstable under weak-grid conditions.
• Mode management: how and when the controller switches between grid-forming and grid-following (and who is allowed to change it).
• Oscillation and interaction limits: your plant’s control loops will meet other converters’ control loops. “Works in the lab” is not a spec.
• Black start and islanding expectations (if applicable): not as marketing features, but as testable sequences and measurable success criteria.

The reason this matters is simple. The moment the inverter is a stability tool, a “small” control choice becomes a large liability. A tuning tweak that increases damping might also reduce energy throughput or increase losses. Now you have a commercial trade hidden inside a control parameter.

2) What to change in your specs: write them like incident tools

Most technical specifications read like catalog shopping. Grid-forming specs must read like you are preparing for a dispute.

I lean on the same principle I use in software delivery: the document is not there to look smart, it is there to shorten recovery time when something goes wrong. If the spec cannot help you diagnose a grid event six months after COD, it is incomplete.

Here is the practitioner’s checklist I would apply before issuing the employer’s requirements or the inverter functional spec.

Spec checklist: the minimum set that changes with grid-forming

• Define the grid strength envelope you expect to operate in (weak-grid conditions, SCR assumptions, harmonic background assumptions). If you do not state it, you will inherit the vendor’s “typical.”
• State performance under constraints: response times, settling times, overshoot limits, and recovery behaviour, not just steady-state droop curves.
• Require a control-parameter governance model: who can change settings, what needs re-validation, and what constitutes a “material change.”
• Specify measurement points and sampling: what signals are logged, at what rate, with what time synchronisation, and how long data is retained.
• Include interaction expectations: behaviour when multiple grid-forming assets operate in parallel, including anti-islanding, power-sharing, and stability margins.
• Define derating logic: what happens at temperature limits, SOC limits, or converter current limits. Stability support often competes with thermal headroom.
• Put test pass/fail numbers in the document, not in someone’s slide deck. “Demonstrate stable operation” is not a criterion.

If this feels heavy, good. The mandate is heavy. It is moving you from “sell energy and capacity” into “sell correct behaviour under stress.”

3) FAT and SAT: stop treating them as ceremonies

Factory acceptance and site acceptance are where projects go to die slowly: too late to change design, too early to see real grid behaviour, and full of ambiguous signoff language.

Grid-forming makes FAT/SAT more important, but also more dangerous, because everyone will be tempted to tick boxes that do not correspond to system reality.

So the change is not “add more tests.” The change is: build an evidence chain that connects three layers.

• Model evidence: simulations that cover the operating envelope you specified, including disturbances and parameter sensitivities.
• Controller evidence: HIL or equivalent that demonstrates the control software does what the model claims.
• Plant evidence: SAT proving the as-built plant matches the assumed signals, latencies, and limits.

This is where many teams get exposed. They have a beautiful model and a passable SAT, but the link between them is missing. When the grid operator later questions performance, you cannot prove equivalence between what you sold and what you built.

FAT checklist: what I would add or tighten

• Disturbance suite: frequency steps, voltage steps, phase jumps, weak-grid emulation, and recovery sequences. Not one “happy path.”
• Parameter sweep: demonstrate stability across an allowed droop and virtual inertia range, not just a single tuned point.
• Latency and timing proof: control-loop timing, comms timing, and trip timing. Grid-forming is timing-sensitive.
• Data capture rehearsal: show that the plant can produce the logs you will need later, with timestamps that can be correlated to grid events.

SAT checklist: what to make non-negotiable

• As-built validation against assumptions: CT/VT polarity, scaling, metering alignment, time sync, protection coordination. Small wiring and scaling mistakes look like “control instability.”
• Grid event readiness: demonstrate that event logs survive a trip, a reboot, and a comms outage. The evidence has to be robust to failure.
• Controlled disturbance tests where permitted: enough to validate dynamic behaviour, not just steady-state export/import.
• Handover package completeness: settings baselines, checksum or versioning, and a clear delta process for future tuning.

One lived lesson: I once watched a cross-functional team lose weeks because nobody could answer a basic question after a field issue, “Which control version is actually running on site?” Not which version was approved. Not which version was emailed. Running. That gap is where claims are born.

4) Grid-code compliance is now a “right to prove” problem

Compliance used to mean: pass a test, get a certificate, file it away. Grid-forming pushes you into ongoing proof.

Because the grid is using your behaviour to manage stability, you should assume that the evidence will be questioned. Not maliciously. System operators and lenders are simply allergic to ambiguity when reliability is on the line.

Your compliance pack needs to be structured like a defensible argument:

• Traceability: every grid-code clause you claim to satisfy maps to a test, a result, and an as-built configuration.
• Configuration control: if settings change, your compliance status is either maintained by rule or explicitly re-validated.
• Event forensics readiness: you can reconstruct what the plant did during a disturbance, using logs that you trust.

This is the same instinct behind “prove innocence” in modern software supply chains. If you cannot prove what you ran and what it did, you are negotiating from weakness. If this topic resonates, the same pattern shows up elsewhere: your right to prove innocence is a competitive advantage, not bureaucracy.

5) The contract shift: stability support creates new downside

This is the part people avoid because it is uncomfortable. A grid-forming mandate moves risk around. If you do not name the risk explicitly, it will land on the party least able to manage it, usually the project owner.

Three risk buckets show up immediately:

• Performance risk: the plant cannot deliver required dynamic behaviour across conditions, even if it meets steady-state ratings.
• Curtailment or dispatch risk: the system operator constrains energy throughput to preserve stability or manage congestion. Revenue shifts.
• Change risk: grid-code interpretation evolves, firmware updates occur, settings are retuned, and suddenly the “as commissioned” plant is not the “as financed” plant.

Who should carry what?

My view: assign each downside to the party that can reduce its probability and cost. If the vendor controls firmware and tuning methodology, they should not walk away at COD with a shrug. If the owner controls market bidding strategy, that is on the owner. If the system operator changes dispatch rules, you need explicit relief events.

Contract checklist: clauses I would insist on revisiting

• Define “grid-forming compliance” as measurable deliverables, not a promise to “meet grid code.” Tie it to the same test criteria in the spec.
• Acceptance criteria linked to evidence: what constitutes final acceptance, and what data must be delivered to support it.
• Performance liquidated damages that reflect dynamic behaviour: not just availability, but inability to meet required response under defined conditions.
• Change control for settings and firmware: who authorises, who tests, who pays, and what happens to warranties after changes.
• Curtailment and dispatch relief events: clear rules for when curtailed operation counts as unavailability (it usually should not) and when it triggers compensation under offtake terms.
• Interaction responsibility: if instability is caused by interactions with other grid assets, define how root cause is determined and how remedial work is funded.

Most disputes are not about physics. They are about poorly written boundaries. If you want a deeper dive on the handover moment, this connects directly to who owns performance risk after the battery is commissioned?

What I would do this quarter if grid-forming just became mandatory

I would not start by buying a different inverter. I would start by tightening the chain between intent, proof, and money.

1. Rewrite the employer’s requirements around behaviour: define the envelope, disturbances, and measurable recovery expectations.
2. Design the evidence pack before procurement: traceability matrix, logging requirements, version control rules, and acceptance data deliverables.
3. Make FAT/SAT a connected proof sequence: model to controller to plant, with explicit equivalence checks.
4. Rebalance the contract: allocate performance, change, and curtailment downsides to the parties who can actually mitigate them.

Grid-forming mandates are a good thing for reliability. They are also a trap for anyone who still treats grid-code compliance as a checkbox. The inverter just became part of grid stability. Your paperwork and your risk allocation need to acknowledge that reality, or the grid will do it for you later, in the form of lost revenue and ugly claims.