A crew replaces a failed distribution transformer and closes the work order from the field. The next morning, the asset register still lists the old unit at that location, so a planner reviewing loading data sees readings attributed to equipment that is no longer in service.
Nothing is missing from either system. Each holds accurate data about its own part of the job, and the problem appears only when the two need to agree on what happened and when.
Connecting applications makes data reachable. Making it usable requires the exchange to carry the right identifiers, the right effective dates, and a clear rule for which system owns each value.
This guide approaches integration as a design problem that starts with the work the data must support, from the relationships applications share to the exchange methods and recovery practices that keep data dependable after go-live. The examples throughout are illustrative.
Defining integration across utility systems
Integration is the work of accessing, exchanging, transforming, and aligning data from separate applications so that it can support a defined operational use. In a utility, those applications typically include customer information, meter data, billing, outage management, asset management, and field work systems.
Each application keeps its own responsibilities. Integration determines how their data can be used together without moving those responsibilities elsewhere, and it carries no inherent requirement for real-time delivery or a central repository.
Data integration and system integration
System integration covers the broader set of interactions between applications, including transactions, process handoffs, and user access. Data integration is narrower. It concerns whether the values moving between systems keep their meaning, relationships, and timing once they arrive.
The two overlap constantly. Sending a service order to a field application is a system interaction, while whether its premise identifier resolves to the correct location is a data question.
Integration and the data fabric
A data fabric describes the broader architecture connecting utility data across many uses, including shared definitions, lineage, and access policy. Individual integrations are the working parts of that architecture.
Each one still has to be scoped, mapped, tested, and supported on its own terms. A well-designed fabric reduces repeated effort, while the requirements of a particular billing or field task still have to be defined individually. The broader utility data foundation can reduce repeated mapping work while preserving the specific requirements of each exchange.
The data relationships utility workflows depend on
Many integration problems in utilities trace back to relationships rather than values. A consumption figure, an account balance, or an asset condition score may be accurate and still mislead if it is attached to the wrong entity or the wrong period.
Before choosing how data will move, it helps to be precise about what must stay connected. Three groups of relationships account for much of the work in utility system integration, and each carries dates that matter as much as the identifiers.
Customers, accounts, and service points
A customer is a person or organization. An account is a financial arrangement with that customer, and a service point is the location where the utility delivers and measures service. One customer may hold several accounts, and one premise may contain several service points.
A move-out and move-in at the same address closes one account and opens another against the same service point on a specific date.
An integration that joins on address alone, or ignores that date, can attribute the prior occupant’s usage or payment history to the new account. The values are correct, and the resulting picture is wrong.
Meters, usage, and billing
Meters are installed at service points for defined periods and are replaced for failure, upgrade, or testing. Usage belongs to the meter that measured it during the interval it was installed. Billing then groups that usage into billing periods tied to an account and a rate.
Each of these links carries a date range. When a meter exchange occurs mid-cycle, the billing period draws on two devices, each with its own start and end reads.
An exchange that sends only the currently installed meter for a service point loses the ability to explain that bill later. The history of the association is part of the data.
Adjustments add another layer. A billing correction can change how an earlier usage value is interpreted without changing the underlying meter data, so the integration needs enough context to distinguish a late transfer from a legitimate correction.
Assets, locations, and work orders
Assets sit at locations, and locations sit within an electrical network and a geography. Work orders reference both, and completed work can change an asset’s condition, configuration, or identity.
The transformer replacement shows the dependency. The field application knows the work is complete, the asset register must retire one unit and install another at the same location, and any loading analysis must follow that change from the correct date forward.
Shared meaning across different utility systems
Once the required relationships are clear, the next question is whether two systems mean the same thing by the same field. A value labeled “usage” in one application may be net consumption over a billing period, while another stores delivered energy in fifteen-minute intervals.
Both are correct inside their own system. A direct mapping between them produces a figure neither system would recognize, which is why utility data interoperability depends on documented meaning as much as on connectivity.
Identifier matching and source ownership
Utility applications rarely share identifiers. A meter may carry a manufacturer serial number in one system, an internal device key in another, and a badge number on the field technician’s screen.
Integration needs a maintained crosswalk that relates these identifiers and tracks when each association began and ended. Without the dates, a crosswalk can only describe the present.
Ownership should be assigned by data element rather than by system. The customer application may own contact details and account status, while the asset application owns equipment attributes for the same location.
When two sources disagree, the integration should defer to the designated owner and flag the conflict for review instead of overwriting silently. Derived values need the same discipline: if a receiving application calculates an indicator from several sources, its inputs and the point in time they represent should remain traceable. Clear ownership is also what makes consistent exchanges between utility applications sustainable as more systems participate.
Units, timestamps, and effective dates
Units and intervals need explicit handling. Kilowatt-hours and megawatt-hours, hourly and daily totals, and delivered and received energy all require conversion and aggregation rules that someone has reviewed and approved.
Time is harder. Event time describes when something happened in the field, while processing time describes when a system learned about it.
A read taken at 11:55 p.m. and loaded at 12:20 a.m. belongs to the earlier day. An integration that uses load time will shift it, and the error may surface only during a later investigation.
Effective dates preserve history. When a meter moves, a rate changes, or an asset is replaced, the prior relationship remains valid for the period it covered. Mappings that retain only current state cannot support billing investigation, reconciliation, or audit review.
Common models and local mappings
Shared data models can provide shared definitions for entities such as customers, service points, meters, and assets, along with standard message structures. Adopting them reduces the number of translation decisions each project must make from scratch.
They leave a meaningful amount of local work. Each utility configures its applications differently, extends fields, and carries historical conventions that no shared model anticipates.
Testing against the utility’s own data and interfaces is still required, even when every participating product supports the same model.
Choosing batch, API, and event exchanges
Exchange design should begin with the task’s timing and reliability requirements, then match a mechanism to them. The three common patterns are scheduled batch transfers, requested access through APIs, and event-driven exchanges.
These patterns are frequently combined, and APIs often carry both scheduled and event traffic. The practical choice concerns how an exchange is triggered, what it depends on, and how it recovers, more than the protocol underneath. The design also needs a clear system integration layer that can support those differing exchange patterns without obscuring their operational purpose.
| Consideration | Scheduled batch | Requested access (API) | Event-driven exchange |
| Trigger | A schedule or processing cutoff | A consuming application asks for data | A source publishes a change |
| Suitable operational need | Reconciliation, billing preparation, periodic reporting | Context during a call or investigation | Downstream updates and notifications after a change |
| Expected freshness | As of the last successful run | As current as the source at request time | Shortly after the source publishes |
| Source-system dependency | Concentrated at run time | Source must be available on demand | Source must emit reliable change events |
| Failure handling | Rerun or resume; confirm completeness | Timeouts, fallback display, retry limits | Duplicate, late, and out-of-order handling; replay |
| Maintenance considerations | File layouts, schedules, cutoffs | Versioned contracts, capacity, credentials | Event definitions, subscribers, monitoring |
Batch processing for scheduled needs
Batch transfers move a defined set of data on a schedule. They suit work that runs on cycles, such as billing preparation, nightly reconciliation between customer and meter data, and periodic regulatory reporting.
Their strength is predictability. A batch has a known cutoff and expected volume, so a count or control total can distinguish an incomplete file from a period with legitimately low activity.
The receiving side also needs to know how corrections arrive. A replacement file, an incremental adjustment, and a restated period each have different consequences for reporting and downstream calculations.
The limitation is freshness. Data is only as current as the last successful run, and a failed overnight job can leave the morning’s work running on the previous day’s picture.
APIs for requested data
An API lets one application request data from another at the moment it is needed. During a high-bill call, a customer service application can request recent usage, meter events, and billing adjustments for one account without copying that data in advance.
Requested access places load on the source at the moment of use. The source must be available, respond within the time the task allows, and enforce permissions for the requesting application.
When it cannot, the consuming application needs a defined fallback. Showing the last known value with its timestamp is more useful to a representative than an error message or a silent gap.
Events for operational changes
Events publish a change when it occurs, such as a completed work order, an approved outage status update, or a meter exchange. Subscribing applications act on the change without repeatedly polling the source.
Each event needs a clear business trigger. Publishing every technical update creates noise for a recipient that only needs an approved status change, so the definition should state the condition that matters, the minimum context included, and the action expected.
Events are well suited to triggering downstream work, and they require discipline. Consumers must handle duplicates, late arrivals, and messages received out of order, and they need a way to recover changes they missed while unavailable.
A periodic batch reconciliation alongside the event stream confirms that nothing was lost. This hybrid arrangement is often the most practical design. An event signals that an account changed, an API supplies its full current context, and a scheduled comparison confirms that both systems agree.
Where faster data adds operational value
Freshness, meaning the age of data at the moment it is used, has value only when a decision or communication changes because of it. The required freshness depends on the task and on how often the source itself updates. Four contrasting examples show how widely those tolerances vary.
Billing investigation and customer calls
When a customer calls about a bill, the representative needs the usage, adjustments, and meter events that apply to that bill while the call is open. Data from the previous night’s batch is usually sufficient for a closed billing period, while a same-day payment or service order may warrant requested access. A customer service capability benefits when that context is available in the interaction rather than reconstructed through separate searches.
Outage updates and customer notifications
Outage communication depends on approved status changes reaching customer channels promptly. The integration should deliver the utility’s approved update, including any estimated restoration time, and should never present unconfirmed field observations as restoration certainty. Enterprise event delivery supports communication and remains separate from grid control.
Asset changes and field coordination
Completed field work should reach the asset register before the next planning or dispatch decision that depends on it. For a transformer replacement, that may mean the same day, while a routine inspection result can often wait for the next scheduled update.
The cost of unnecessary immediacy
Near-immediate delivery requires more monitoring, more capacity on source systems, and more careful handling of ordering and duplicates. If a source updates once a day, streaming its data every minute adds complexity without improving the task.
Keeping integrations dependable as systems change
Consider a nightly transfer of meter reads that stops partway through after a network interruption. By morning, some accounts have complete data, some have partial data, and some have none.
Recovery requires answering three questions in order: what was expected, what arrived, and what can be safely resent. Many persistent integration challenges surface in this kind of situation, well after go-live, when the original project team has moved on.
Validation and reconciliation
Validation checks each exchange against two kinds of rules. Schema validation confirms structure, data types, and required fields.
Business-rule validation confirms that values make operational sense, such as a read that falls within an expected range for the meter or a service point that exists and is active. Both should run before data reaches the consuming application.
The rules should reflect the task as well as the interface. A billing-support exchange can pass every field check and still attach a charge explanation to the wrong account period, which leaves the representative unable to use it.
Completeness checks compare what arrived with what was expected. A control total, an account count, or a count of intervals per meter gives the receiving side a basis for confirming that a transfer finished.
Reconciliation compares the two systems after the fact. A scheduled comparison of active service points, installed meters, and open accounts in the customer and meter applications will surface mismatches that individual messages never reveal. Each mismatch needs an owner, a priority, and a resolution path.
Failed transfers and safe retries
Retrying a failed transfer is safe only if the receiving system can accept the same data twice without creating duplicates. That property depends on stable identifiers for each message or batch and on logic that recognizes data already applied.
Retrying alone does not guarantee recovery. A successful connection says nothing about whether every expected item arrived, and some failures come from source data, configuration, or an application change rather than an unavailable system. Resending the same payload will fail again.
Those messages should move to an exception queue with enough detail for the receiving team to identify the cause and route it to the owner who can resolve it. A subject matter expert can then review, correct, and release them, while a limit on automatic retries keeps a single malformed message from consuming capacity indefinitely.
Late and revised data raise their own questions. If a revised billing input arrives after the original was processed, the integration must determine whether the revision replaces the original, adjusts it, or requires review before anything changes downstream.
Replay, the ability to resend a defined window of historical messages, supports recovery after an extended interruption. It works only when consumers can apply replayed data in the correct order and recognize what they have already processed.
Interface changes and monitoring
Source systems change. Application upgrades add fields, rename values, or alter behavior, and each change can affect every consumer of that data.
Versioned interfaces allow a source to introduce a change while existing consumers continue on the prior version until they are tested.
Monitoring should report on the data as well as the infrastructure. A connection can remain available while delivering empty files, stale values, or a sudden drop in volume.
Useful alerts track freshness against the agreed requirement, volume against expected ranges, and the count and age of open exceptions. Thresholds should reflect the consequence of delay: a late overnight reconciliation can wait for the next business cycle, while a stale value shown during a live customer call may need a visible notice to the representative.
Support responsibilities, escalation paths, and hours of coverage belong in the integration design, particularly for supporting interfaces across existing systems that several teams rely on.
Access controls and system boundaries
Every integration grants one system access to another’s data. Service accounts should hold only the permissions their task requires, credentials should be stored and rotated under the utility’s security policy, and access should be logged for review.
Read access, transformation, and write-back carry different risks and should be permitted separately. A correction found downstream should return through the owning system’s process unless the integration explicitly supports an approved update path.
Boundaries matter as much as permissions. Integrations that draw on operational technology environments require the separation and review those environments demand, and operational sensor data leaving them should be consumed under defined conditions.
Interoperability and security are separate design concerns. A shared data definition establishes meaning, while access controls, encryption, and monitoring establish protection.
Proving one integration before expanding coverage
Expansion should follow evidence that an integration meets its defined requirements. A narrowly scoped exchange, such as delivering billing context to a customer service application or updating the asset register from completed field work, provides that evidence with limited exposure. The sequence below applies to either.
Define the operational task
State the decision or communication the data supports, who performs it, and what happens when the data is late or missing. That statement becomes the reference for every later test.
Map required data and dependencies
List each data element, its owning system, its identifier, its effective dating, and its freshness requirement. Note dependencies on other interfaces and on source-system schedules.
Test exceptions with representative data
Use test data that includes meter exchanges, move-ins, split billing periods, duplicates, and late arrivals. Exceptions reveal more about an integration than clean samples do.
Measure accuracy, timeliness, and effort
Define each measure before testing begins. Completeness is the share of expected data that arrived, accuracy is the share of delivered values that match the owning system, and timeliness is the delay between a source change and its availability to the task.
Effort is the manual work still required to resolve exceptions and maintain the interface. Acceptance criteria should be observable for the exchange type, such as completion within a defined window for a batch, defined behavior during source unavailability for an API, or correct handling of delayed and duplicate messages for events.
Those criteria, agreed with ongoing support responsibilities before production use, show whether the integration is ready, needs revision, or should stay limited to a narrower task. They also show what can be reused in the next integration.
Reliable utility integration supports AI-assisted analysis
AI capabilities that assemble utility data, flag discrepancies, or prepare explanations inherit the strengths and weaknesses of the integrations feeding them. An AI-assisted billing explanation is only as sound as the usage, meter history, and adjustments it receives.
The architectural questions involved in connecting AI capabilities to existing utility systems follow directly from the requirements above. Gigawatt applies them through modular AI capabilities that use connected data alongside existing systems of record, with its Data Foundation and Integration capabilities supporting the exchange.
Source context and data freshness
An AI-assisted analysis should show which systems supplied its inputs and how current each input was. A reviewer can then judge whether a conclusion rests on today’s data or last week’s.
Missing data and human review
When a required input is missing or conflicting, the AI capability should say so and route the question to a person instead of filling the gap. Source conflicts are resolved by the owning system and its subject matter experts, and the AI output should keep those conflicts visible.
Approved write-back for AI-assisted workflows
Where an AI-assisted workflow proposes an update, such as a billing adjustment, the change should pass through the same approval steps and interfaces that govern manual updates. The system of record remains the place where the change is applied and retained.
Build integration around operational requirements
Dependable utility data integration begins with a specific operational task and works backward to the data it requires. The relationships to preserve, the owner of each value, the exchange pattern, the freshness tolerance, and the recovery path all follow from that task.
A utility does not need to connect every system at once to make progress. One bounded exchange, tested against realistic exceptions and assigned ongoing support, gives the utility evidence to extend coverage deliberately. That proof includes more than successful delivery: it shows that the receiving team can understand the data, identify failures, resolve exceptions, and continue operating when source systems change.
Over time, those tested exchanges create a more reliable foundation for billing, customer service, field work, asset planning, and AI-assisted analysis. The objective is not integration for its own sake. It is dependable information for the decisions and communications that keep utility operations moving.
Which of your utility’s operational tasks depends most on data held in more than one system? Download The Utility Modernization Playbook to sequence integration within a broader adoption plan.