A connection register is a structured database that tracks every grid connection project your team manages. It records the project status, technical parameters, documents, DNO correspondence, key dates, and commercial data in one place.

Most grid engineering teams use some form of connection register, even if they call it a project tracker or master spreadsheet. The difference between a proper register and a loose tracker determines whether your team can scale.

What Goes Into a Connection Register

A complete connection register contains these data fields for every project.

Core Project Data

• Project reference: Unique identifier for the connection project
• Site name and address: Physical location of the connection
• Client name: The developer or asset owner
• DNO/VNB/OSD region: Which network operator covers the site
• Connection voltage: LV, HV, or EHV connection level
• Capacity (MW/MVA): Requested import and export capacity
• Technology type: Solar, wind, BESS, hybrid, or demand

Status and Timeline

• Application date: When the connection application was submitted
• Connection offer date: When the DNO issued the connection offer
• Offer acceptance deadline: Contractual deadline for accepting the offer
• Estimated energisation date: Target date for the connection to go live
• Current status: Applied, offered, accepted, in construction, energised, or withdrawn

Technical Parameters

• Point of connection: The specific busbar or substation where the connection is made
• Fault level at POC: Three-phase and single-phase fault levels at the connection point
• Available capacity: Remaining capacity at the connection point
• Protection settings: G99/VDE-AR-N 4110/IRiESD protection relay settings
• Metering arrangement: Import/export metering configuration

Document Register

• Application form: Reference and version
• Connection offer letter: Reference, date, expiry
• Connection agreement: Signed/unsigned, date
• Study reports: Load flow, fault level, protection coordination
• As-built drawings: Final single-line diagrams and layout plans
• Commissioning certificates: Test results and sign-off documents

How It Differs From a Project Tracker

A project tracker tells you what needs to happen next. A connection register tells you the complete history and current state of every connection.

Most teams need both. But the connection register is the single source of truth that the project tracker references.

Why Manual Registers Break

Teams that maintain connection registers in Excel or Google Sheets eventually hit the same problems.

Version Conflicts

Two engineers update the same spreadsheet simultaneously. One saves over the other's changes. Data is lost without anyone knowing.

Stale Data

An engineer updates the connection status in the register but forgets to update the fault level data. The register shows a project as "accepted" with outdated technical parameters.

Missing Documents

The register says "connection offer received" but does not link to the actual document. Three months later, nobody can find the PDF.

No Audit Trail

A capacity value changed from 5 MW to 8 MW. When? By whom? Why? The spreadsheet does not tell you.

Scale Limits

At 50 connections, the spreadsheet is manageable. At 200, it slows down. At 500, it is unusable. Filtering, sorting, and cross-referencing become painful.

What a Proper Connection Register Looks Like

A well-built connection register has these properties.

• Structured schema: Every field has a defined type, format, and validation rule. No free-text fields where structured data should be.
• Linked documents: Every entry links to the actual files (applications, offers, drawings) stored in a central location.
• Automatic status updates: When a new document is uploaded or a date passes, the status updates automatically.
• Role-based access: Engineers see technical data. Commercial teams see financial data. Clients see their own projects.
• Search and filter: Find any connection by site, DNO region, status, capacity range, or date range in seconds.
• Export and reporting: Generate portfolio reports, DNO summaries, and client updates from the register data.

How Noda Builds a Connection Register Automatically

Noda creates a connection register from the files your team already produces.

• File parsing: When you upload a DNO data file, connection offer, or study report, Noda extracts the key data points and populates the register automatically
• Document linking: Every register entry links to the source documents stored in Noda
• Status detection: Noda reads document types and dates to determine the current project status
• Cross-referencing: Noda matches connection points across different data sources (DNO fault level data, connection offers, network diagrams) to build a unified view
• Portfolio view: See all your connections on a single dashboard with filtering by DNO, status, capacity, and technology type

Instead of maintaining a spreadsheet manually, the register builds itself from your working documents.

Key Takeaways

• A connection register is a structured database of all grid connection projects, distinct from a project tracker which focuses on tasks
• Manual registers in Excel break at scale due to version conflicts, stale data, missing documents, and no audit trail
• An automated register that builds itself from project documents eliminates manual data entry and keeps data current

Next Steps

If your connection register is a spreadsheet that someone has to update manually, it is already out of date. Book a demo to see how Noda builds a connection register automatically from the files your team already works with.

Every grid engineering team starts with Excel. It is flexible, familiar, and free. But as project volumes grow, the spreadsheet workflow breaks. Copy-paste errors multiply, version control disappears, and a single misplaced formula can invalidate an entire connection study.

This guide compares manual Excel workflows against automated data pipelines for grid connection studies, with real numbers on time, accuracy, and cost.

Side-by-Side Comparison

Where Excel Works

Excel is not always the wrong choice. For small teams with low project volumes, it remains practical.

Excel is acceptable when:

• Your team runs fewer than 10 connection studies per month
• You work with a single DNO and their format does not change
• One person owns the entire workflow end to end
• You do not need to produce audit trails for regulatory compliance

Excel becomes a problem when:

• Multiple engineers share and edit the same data files
• You process data from 3 or more DNOs with different formats
• Project volumes exceed 20 studies per month
• Clients or regulators require documented data lineage

The Five Costs of Staying on Excel

1. Time Cost

A senior grid engineer spends 4 to 8 hours per study on data preparation alone. This includes downloading DNO data, mapping columns, checking for errors, converting formats, and importing into modelling software.

At 20 studies per month, that is 80 to 160 hours of engineering time spent on data preparation. At a fully loaded cost of 75 GBP per hour, the annual cost is 72,000 to 144,000 GBP in engineering time alone.

2. Error Cost

Research by Raymond Panko (University of Hawaii) found that 88% of large spreadsheets contain errors. In grid engineering, a single wrong fault level value can lead to an under-rated protection scheme, a failed commissioning test, or an unsafe installation.

The cost of a data error that reaches the study output is 10x to 100x the cost of catching it during data preparation.

3. Knowledge Cost

When the engineer who built the spreadsheet leaves, the knowledge walks out the door. Undocumented macros, hidden columns, and implicit assumptions make handover painful.

4. Scalability Cost

Doubling project volume in a spreadsheet workflow means doubling headcount. There is no economy of scale. Every new project requires the same manual steps.

5. Compliance Cost

Ofgem, BNetzA, URE, and ANRE increasingly require documented data lineage for connection studies. A spreadsheet with no change history does not meet this standard.

When to Switch: A Decision Framework

Use this framework to assess whether your team should move from Excel to an automated pipeline.

Score 0 to 4: Excel is probably fine. Revisit in 6 months. Score 5 to 9: Start evaluating automation tools. The ROI is positive within 6 months. Score 10+: You are losing money every month. Switch now.

Real Numbers: The PowerGrid Case

PowerGrid Solution, a Romanian grid engineering firm, processed connection studies using Excel for years. When they adopted Noda:

• Before Noda: 3 weeks per documentation set, 4 disconnected file formats (Excel, CSV, PDF, DXF), errors caught only at client delivery
• After Noda: 4 minutes for data reconciliation, zero duplicates in deliverables, senior engineers back on design work
• Result: 95% time reduction, 312 substations processed, 35,000+ rows per file reconciled automatically

The engineering team onboarded without a single training session.

What an Automated Pipeline Looks Like

An automated grid engineering data pipeline replaces the manual steps with software.

1. Data ingestion: Upload the DNO/VNB/OSD data file. The system identifies the operator, format, and version automatically.
2. Column mapping: Columns are mapped to a standard schema. No manual matching required.
3. Validation: Every value is checked against expected ranges, naming conventions, and internal consistency rules.
4. Error flagging: Issues are categorised (error, warning, info) and presented in a report. No silent failures.
5. Format conversion: Data is exported in the format your modelling tool expects (IPSA, PSS/E, PowerFactory, DIgSILENT).
6. Audit trail: Every step is logged with timestamps, input hashes, and user IDs.

Key Takeaways

• Excel works for small teams with low volumes but breaks at scale due to errors, knowledge loss, and compliance gaps
• The hidden cost of manual data preparation is 72,000 to 144,000 GBP per year for a team running 20 studies per month
• A structured decision framework based on volume, DNO count, and compliance needs helps you determine the right time to switch

Next Steps

Calculate your own data preparation cost with the framework above. If the numbers point to automation, book a demo to see how Noda replaces your Excel data preparation workflow with an automated, validated pipeline.

A G99 connection application is the standard process for connecting generation above 3.68 kW (single-phase) to the UK distribution network. Getting it right the first time saves weeks. Getting it wrong means resubmission, delays, and missed project deadlines.

This checklist covers every document, data point, and form required for a successful G99 application, plus the mistakes that cause the most rejections.

Before You Start: Determine Your Application Type

G99 defines different application routes based on the size and type of your installation. Your route determines the documents you need.

If your installation requires a Statement of Works (SoW), the DNO will request NESO assessment of transmission impact. This adds 3 to 6 months to the timeline.

The Complete Document Checklist

Every G99 application needs these core documents. Missing any one causes rejection.

Required for All Applications

• Application form: DNO-specific form (each DNO has its own version). Download from the DNO portal.
• Site plan: Ordnance Survey map showing the site boundary, point of connection, and proposed cable route. Scale 1:2500 or better.
• Single-line diagram: Electrical schematic showing all generation, switchgear, protection, and metering from the point of connection to each generator. Must include CT/VT ratios.
• Equipment datasheets: For every inverter, generator, transformer, and switchgear item. Must include fault ratings, impedance values, and frequency/voltage response curves.
• Protection settings schedule: Proposed settings for G99 interface protection. Must cover frequency, voltage, RoCoF, and vector shift.
• Earthing arrangement: Drawing and calculation showing the proposed earthing system, step and touch voltage compliance.

Additional for Stage 2 and 3

• Fault level contribution data: Three-phase and single-phase fault current contribution from each generator/inverter at the point of connection.
• Reactive power capability chart: P-Q diagram showing the available reactive power range across the operating envelope.
• Frequency response data: Governor droop settings, frequency deadband, and response time constants.
• Fault ride-through (FRT) curves: Voltage versus time curves showing the installation can ride through voltage dips per G99 requirements.
• Power quality assessment: Harmonic current injection data (up to 50th harmonic), flicker coefficients, and voltage step change calculations.

Additional for Stage 3 (Above 10 MW)

• System study results: Load flow, fault level, and voltage step change study results using the DNO's network model or approved equivalent.
• SoW application form: If the DNO determines a Statement of Works is required. This triggers a separate NESO assessment.
• Compliance matrix: Mapping of every G99 technical requirement to the proposed installation design.

DNO-Specific Requirements

Each DNO adds its own requirements on top of the standard G99 documents. These are the most common sources of confusion.

UKPN (South East, East, London)

• Uses the ENA G99 application form with UKPN-specific supplementary questions
• Requires IPSA or PSS/E format network model data for studies above 5 MW
• Earthing report must follow UKPN's specific template for HV connections
• Separate forms for Type A (up to 1 MW) and Type B/C/D installations

NGED (Midlands, South West, South Wales)

• Uses its own NGED application portal with digital form submission
• Requires DigSILENT PowerFactory format for network studies
• Additional noise assessment for generator installations near residential areas
• Provides pre-populated network data through its Connected Data Portal

SSEN (North Scotland, Central Southern)

• Requires paper-based forms for some Scottish regions (digital for Southern)
• Additional winter minimum fault level check for remote Scottish networks
• Longer processing times in northern regions due to limited network capacity
• Requires SHEPD-specific protection relay settings for North Scotland

Common Mistakes That Cause Rejection

These errors account for over 60% of G99 application rejections across UK DNOs.

1. Wrong Protection Settings Format

DNOs expect protection settings in a specific format. Submitting generic inverter datasheet values instead of calculated G99 protection settings is the most common rejection reason.

• RoCoF: Must specify both the setting value (Hz/s) and the measurement window (ms)
• Vector shift: State clearly if enabled or disabled, and the degree setting if enabled
• Voltage stages: Provide all four voltage protection stages (UV1, UV2, OV1, OV2) with time delays

2. Incomplete Single-Line Diagram

The single-line diagram must show every component from the grid connection point to the generators. Common omissions include:

• CT and VT locations and ratios
• Isolator switch positions
• Earthing connections
• Metering locations (generation and export)

3. Mismatched Capacity Values

The capacity stated on the application form must match the equipment datasheets and single-line diagram. Any mismatch triggers a query that delays processing by 2 to 4 weeks.

4. Missing Fault Level Data

Applications above 1 MW require fault current contribution data. Submitting the application without this data means automatic rejection.

5. Incorrect Site Plan

Site plans must use Ordnance Survey mapping. Google Maps screenshots or hand-drawn plans are not accepted. The connection point and cable route must be clearly marked.

How Noda Generates Compliant Document Sets

Noda automates the preparation of G99 application packages.

• Auto-populated forms: Noda fills DNO-specific application forms from your project data, ensuring no fields are missed
• Protection settings calculator: Calculates G99-compliant protection settings from your equipment datasheets
• Single-line diagram generator: Creates compliant diagrams from your equipment list and site configuration
• Compliance checker: Validates every document against G99 requirements and DNO-specific rules before submission
• Multi-DNO support: Same project data, different output formats for UKPN, NGED, SSEN, SPEN, NPG, and ENW

The result is a complete, validated application package that passes first-time review.

Key Takeaways

• G99 applications require 6 to 12 documents depending on the installation size and DNO
• Each DNO adds specific requirements on top of the ENA standard, particularly around study formats and protection settings
• Over 60% of rejections come from five common mistakes: wrong protection format, incomplete single-line diagrams, mismatched capacity, missing fault data, and incorrect site plans

Next Steps

Stop losing weeks to G99 application rejections. Book a demo to see how Noda generates complete, DNO-compliant application packages from your project data.

Fault level data is the foundation of every connection study. When the data is wrong, your load flow and short circuit results are wrong too. Most engineers discover data errors after running the study, not before. That costs days of rework.

This guide covers the most common fault level data errors found in DNO exports, a step-by-step validation process, and how to automate the entire check.

Common Errors in Fault Level Data

DNO fault level data arrives in formats ranging from structured CSV exports to hand-edited Excel files. Across UK DNOs, these are the errors that appear most often.

Missing Fault Level MVA Values

The most frequent error is missing or blank fault level MVA fields. This happens when DNOs export partial datasets or when busbars are included as placeholders without calculated values.

• Blank cells in the fault level column where a value between 250 and 2,000 MVA is expected
• Zero values that indicate the field was defaulted rather than calculated
• Placeholder text like "TBC" or "N/A" in numeric fields

Zero or Negative X/R Ratios

The X/R ratio (reactance to resistance) determines fault current decay characteristics. Valid ratios for HV and EHV busbars typically fall between 5 and 15.

A zero X/R ratio will cause division errors in short circuit calculations. Negative values indicate data corruption or sign convention errors in the source system.

Inconsistent Busbar Naming

DNO systems use different naming conventions for the same physical busbar. When you merge data from multiple sources, busbar name mismatches create duplicate nodes in your model.

• UKPN might label a busbar as "KINGS_33" while the same busbar appears as "Kings Cross 33kV" in a different dataset
• NGED uses numeric prefixes like "2140_BRIDGWATER_33" while the load flow model uses "Bridgwater 33"
• Voltage suffixes vary: "_33", "_33kV", "33KV", "33 kV"

Stale or Outdated Values

Fault levels change as the network evolves. Data from 2 or more years ago may not reflect recent reinforcement, new generation connections, or decommissioned assets.

• Compare the data date field against the study date
• Check if the dataset version matches the DNO's latest published fault level data
• Flag any values that differ by more than 10% from the previous dataset for the same busbar

Step-by-Step Validation Process

Follow this sequence before importing fault level data into any power system modelling tool.

Step 1: Check File Completeness

Before looking at individual values, confirm the file is complete.

• Count the number of busbars. Compare against the expected number for the DNO region and voltage level.
• Verify all required columns exist: busbar name, voltage level, three-phase fault level (MVA), single-phase fault level (MVA), X/R ratio.
• Check for truncated rows at the end of the file. Some CSV exports cut off at row limits.

Step 2: Validate Ranges

Apply boundary checks to every numeric field.

Values outside these ranges are not always wrong, but they need a second look. A 400 kV busbar with a fault level below 1,000 MVA, for example, is worth checking.

Step 3: Cross-Reference Busbar Names

Match busbar names against a reference list. If you do not have one, build it from the DNO's published network data.

• Normalize naming: strip spaces, convert to uppercase, remove voltage suffixes
• Use fuzzy matching to catch near-duplicates like "BRIDGWATER" vs "BRIDGEWATER"
• Map each busbar to a unique network node ID

Step 4: Check Consistency Between Fields

Fault level values, voltage, and X/R should be internally consistent.

• Higher voltage busbars generally have higher fault levels
• X/R ratios increase with voltage level (transmission X/R is higher than distribution)
• If three-phase fault level is present but single-phase is missing, flag it

Step 5: Compare Against Previous Data

If you have fault level data from a previous study or dataset version, compare the two.

• Identify busbars where fault level changed by more than 15%
• Check if new busbars appeared or old ones disappeared
• Document changes and verify them against known network modifications

How Noda Automates Fault Level Validation

Noda runs this entire validation process automatically when you upload a DNO fault level file.

• Format detection: Noda identifies the DNO and file format (UKPN, NGED, SSEN, SPEN, NPG, ENW) and maps columns to a standard schema
• Range checks: Every numeric field is checked against voltage-level-specific thresholds, not just global ranges
• Name matching: Noda maintains a reference database of over 50,000 UK busbars and matches incoming names using fuzzy logic
• Version comparison: If you have uploaded a previous dataset, Noda highlights what changed and flags anomalies
• Validation report: A summary report lists every issue found, categorised by severity (error, warning, info)

Instead of spending 2 to 4 hours manually checking a spreadsheet, the validation completes in under 30 seconds.

DNO-Specific Gotchas

Each DNO has quirks in how they export fault level data.

• UKPN: Exports separate files for winter maximum and summer minimum fault levels. Make sure you are using the correct season for your study scenario.
• NGED: Uses internal busbar IDs that do not match published network diagrams. You need a mapping table.
• SSEN: Often provides fault level data as PDF tables rather than structured data. This requires extraction before validation.
• SPEN: Includes both make and break fault levels. Verify which value your modelling tool expects.
• NPG: Data format changed in 2024. Older scripts may fail on the new column layout.

Key Takeaways

• Missing MVA values and zero X/R ratios are the most common fault level data errors across all UK DNOs
• A five-step validation process (completeness, ranges, naming, consistency, comparison) catches 95% of data issues before they affect your study
• Automated validation reduces a 2 to 4 hour manual task to under 30 seconds and eliminates human oversight errors

Next Steps

If your team spends hours checking fault level data before every connection study, there is a faster way. Book a demo to see how Noda validates DNO data files automatically and flags every issue before it reaches your model.

If you file grid connections in the UK, you already know: there is no single format. Every DNO has its own portal, its own templates, its own way of expressing the same technical data.

The six DNOs

The UK distribution network is split between six licensed operators:

• UK Power Networks (UKPN) — South East, East of England, London. Three licence areas under one brand.
• National Grid Electricity Distribution (NGED) — Midlands, South West, Wales. Rebranded from Western Power Distribution in 2023 after National Grid acquired it from PPL Corporation.
• Northern Powergrid — Yorkshire, North East England.
• SP Energy Networks (SPEN) — Central and Southern Scotland (SP Distribution) plus Merseyside and North Wales (SP Manweb). Two licence areas.
• SSE Networks (SSEN) — North of Scotland and South of England. Two geographically separate licence areas.
• Electricity North West (ENW) — North West England. Single licence area.

Above them sits NESO (National Energy System Operator), which took over from National Grid ESO in October 2024. NESO manages the 400kV/275kV/132kV transmission network and handles connections above 132kV directly.

The connection process

For generators above the G98 threshold (>3.68kW single-phase), you file a G99 application:

1. Pre-application — initial enquiry to the relevant DNO with site location, technology type, and requested capacity.
2. Stage 1 feasibility — DNO assesses whether the local network can accommodate the connection.
3. Stage 2 detailed design — full grid impact study. The DNO issues a Connection Offer (Formal Offer Letter) within 65 working days for straightforward applications.
4. Statement of Works — details the civil and electrical works required on the DNO side.
5. Design Acceptance — DNO signs off the applicant's plant design before energisation.

For small installations under G98, it is a simplified notification — the installer notifies the DNO within 28 days of commissioning.

What makes this painful for engineers

Every DNO uses different forms, portals, and document templates. UKPN has one online portal. NGED has another. SSEN has a third. The data you submit is essentially the same — site coordinates, single-line diagram, protection settings, export capacity — but the format changes every time.

Connection Offers arrive as PDFs with no machine-readable structure. Your engineer manually re-enters parameters from the PDF into the project's Excel model. A misread digit — 250 MVA instead of 315 MVA — propagates through the entire protection coordination study.

Protection settings vary by DNO. Even where ENA Engineering Recommendation G99 is the common standard, each DNO interprets relay settings and export limiting requirements differently.

Queue management is inconsistent. NGED and SSEN in particular have had multi-year backlogs for HV connections. Stage 1 to Stage 2 progression timescales vary significantly, and some DNOs request additional information not covered by the standard G99 form.

The regulator's push

OFGEM regulates all DNOs under the RIIO-ED2 price control (2023-2028). Their 2023-2024 Connections Action Plan pushed DNOs to publish queue data publicly and reduce backlogs. ENA published G99 Amendment 7 in 2023 to address battery storage and hybrid plant connection rules.

But none of this standardises the data format. Each DNO still issues its own Connection Offer template, its own Statement of Works format, its own protection settings schedule.

What this means for your workflow

If your firm files connections across multiple DNO areas, you are maintaining separate data extraction workflows for each one. The same rated short-circuit current appears in six different formats across six different PDFs.

noda normalises all of them into one canonical schema. Drop the Connection Offer from UKPN, the Statement of Works from NGED, the protection schedule from SSEN — the system maps every field to the same structure, flags inconsistencies, and regenerates your schedule of parameters from structured data.

Book a free demo call — we will look at your actual DNO files and show you the mapping.

Published by Pica Ovidiu. noda builds the data layer for grid engineering.

Every grid engineer knows the feeling. You spent two days building a perfect schedule of parameters — fields mapped, formulas linked, cells formatted for the operator's template. Then a revised Connection Offer arrives. Three columns shifted. Two parameters renamed. One transformer rating changed from 250 to 315 MVA in a footnote nobody flagged.

Your schedule of parameters is now broken. Again.

The problem isn't you. It's the workflow.

Grid operators across Europe all send technical data in their own formats. There is no standard. Every DNO has a different column order, a different naming convention, a different way to express the same rated short-circuit current.

When your team builds a schedule of parameters manually:

• Column mapping is implicit. It lives in one engineer's head. When they're on holiday, nobody knows which column in the operator's file maps to which row in your schedule.
• Duplicate detection is manual. The same busbar appears in three files with slightly different names. Your engineer spots two of them. The third becomes a phantom row in the final deliverable.
• Revision tracking is nonexistent. When the operator sends v3, nobody can tell you exactly what changed from v2 without a side-by-side Excel diff that takes an hour to set up.

What breaks, specifically

Let's be precise. Here's what typically goes wrong when a revision lands:

1. Hard-coded cell references snap. Your formula in cell G47 pointed to the Connection Offer file, sheet 2, cell D12. The operator inserted a row. D12 is now D13. Your schedule still reads the old cell. Nobody notices until the technical report goes to review.

2. Parameter names drift. The original Connection Offer called it "Rated short-circuit current." The revision calls it "Isc." Your VLOOKUP returns #N/A. You fix it, but only for this column — the same drift happened in five other places.

3. Units change silently. The substation file had impedance in ohms. The revision switched to per-unit values. Your calculation downstream assumes ohms. The protection coordination study is now wrong.

4. Duplicate rows multiply. The revision added a new line for a second transformer. But it also kept the old one with slightly different parameters. Your schedule now has both, and the operator will reject the deliverable.

What good teams do (and why it still fails)

The best engineering teams we've spoken to have partial solutions:

• Color-coded Excel templates with locked cells and dropdown validations. Works until the operator sends data in a format that doesn't match the template.
• A senior engineer who reviews every schedule of parameters. Catches 90% of errors, but creates a bottleneck. That engineer becomes the single point of failure for every project.
• Side-by-side file comparison using Beyond Compare or WinMerge. Helps with text diffs, but doesn't understand that "TR1 250MVA" and "Transformer 1 (250 MVA)" are the same entity.

None of these scale. When your firm goes from 5 concurrent projects to 15, the manual approach collapses.

What a structured data layer looks like

Imagine instead:

1. You drop the operator's files — Connection Offer, substation studies, contract annexes, whatever format they arrive in.
2. The system maps every column to a canonical schema, regardless of the operator's naming convention.
3. When a revision arrives, you drop it next to the original. The system shows you exactly what changed: which parameters shifted, which rows were added, which values differ.
4. Duplicate detection runs automatically. "Busbar 110kV Section A" and "110 kV Busbar (Section A)" get flagged as the same entity.
5. Your schedule of parameters regenerates from the structured data. No broken cell references. No phantom rows.

This is what noda builds. Not a replacement for the engineer's judgment — a replacement for the fragile Excel plumbing that breaks every time the operator sends a revision.

The math

A typical Connection Offer revision cycle costs an engineering team:

• 2-4 hours to manually diff the old and new files
• 1-2 hours to update the schedule of parameters
• 1 hour for the senior engineer to review and catch what was missed
• 0.5-1 hour to fix what the review caught

That's a full engineering day, per revision, per project. Most projects see 2-3 revisions before the final Connection Offer. Multiply by your project volume.

For a firm handling 20 projects per year with an average of 2.5 revisions each, that's 50 engineering days per year spent on file cleanup — the salary of a junior engineer — spent on work that adds zero engineering value.

What to do next

If your schedule of parameters broke this week, you're not alone. The workflow is the problem, not your team.

We built noda specifically for this. Drop your operator files, get structured data, regenerate deliverables when revisions arrive. Every number traceable back to its source.

Book a free demo call — we'll look at your actual files and show you where the breaks happen.