Reference · built on requestOperator by FibricEnergy & demand

Bill Reconcile

Each utility invoice checked against interval meter data and the rate on file, with a dispute or corrected payable proposed for mismatches.

About

Utility bills are paid on trust because nobody has time to recompute them. This operator reads each bill as the utility publishes it, as a Green Button UsageSummary with billLastPeriod and itemised costAdditionalDetailLastPeriod lines, through UtilityAPI, or as a PDF in a bucket. It totals the same period from the utility's IntervalBlock data or your own Modbus TCP meters and re-prices it with the rate record from the OpenEI Utility Rate Database.

When billed usage or charges differ beyond your tolerance, it proposes one action: a dispute in your words, a corrected payable on the NetSuite vendor bill, or a hold until the utility answers. A person approves; the receipt keeps the original amounts.

This is a reference listing. It documents what Fibric would read from Bill Reconcile and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • UsageSummary entries from Green Button Connect My Data: billingPeriod with start and duration, billLastPeriod, billToDate, and costAdditionalLastPeriod
  • Line items in costAdditionalDetailLastPeriod, each with amount, note, and itemKind, reported in hundred-thousandths of the currency
  • IntervalBlock readings under each MeterReading, and the same period totalled from your own interval meters over Modbus TCP
  • The rate on file from the OpenEI Utility Rate Database: energyratestructure tiers, demand structures, and fixedchargefirstmeter
  • Vendor bills for the utility vendor in NetSuite, read as the vendorBill record with entity, item and expense lines, amount, and memo
  • Invoice PDFs landing in an Amazon S3 bucket, or bills fetched through UtilityAPI, where the utility offers no Green Button feed

Proposed actions

  • Target capability: propose a dispute to the utility when billed consumption differs from the interval total beyond your tolerance
  • Target capability: propose a corrected amount on the NetSuite vendor bill, with the recomputed charges beside the billed ones
  • Target capability: propose a hold on the vendor bill until the utility answers, so the payment run skips it
  • Target capability: propose flagging a billed line whose itemKind or note matches no charge in the rate on file
  • Target capability: propose closing an exception as accepted, with the reason, when an estimated read is later trued up by the utility

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Green Button bill against the interval feed

    The UsageSummary for the month is re-priced from its own IntervalBlock data and the URDB record. A demand charge billed on a higher kW than the intervals show is proposed as a dispute.

    With Green Button Connect My Data, OpenEI Utility Rate Database

  • Hold the payable before the run

    Where your Modbus TCP main meter totals less than the billed kWh by more than your tolerance, the NetSuite vendor bill is proposed for hold, with both totals attached.

    With NetSuite, Modbus TCP

  • Utilities with no Green Button feed

    Bills fetched through UtilityAPI or dropped as PDFs into an Amazon S3 bucket are extracted and checked the same way, and a corrected payable is proposed when a line item does not match the rate.

    With UtilityAPI, Amazon S3

Requirements

  • Utility usage and bill data: a Green Button Connect My Data authorization, UtilityAPI, or invoice files in a bucket
  • Interval data for the period each bill covers, from your Modbus TCP meters or the utility's IntervalBlock entries
  • The URDB record for your rate, or the tariff document, so charges can be recomputed line by line
  • A NetSuite role that can read and update vendor bills for the utility vendor, and a hold mechanism the payment run respects
Authentication
It has no login at the utility or in your ledger. Bills arrive through the Green Button authorization, UtilityAPI, or bucket connector you attach; NetSuite is reached with the role you assign it.

Limits

  • Recomputation is only as good as the rate on file. A rider or rate change missing from URDB appears as a mismatch you must explain.
  • A utility meter and your submeter rarely agree to the kWh. You set the tolerance, and below it no exception is raised.
  • A bill that arrives only as a scanned PDF is read by text extraction. A page that fails extraction is queued for a person.
  • It drafts the dispute. It does not send it to the utility or touch the bill inside the utility's own system.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Bill Reconcile ↗

Questions and answers

What does the AP reviewer approve?
An exception per bill: billed kWh and amount, the recomputed values, the lines that differ, and one proposed action, either a dispute, a corrected payable, a hold, or accept. The approver can edit the amount or the dispute text.
What is kept for each bill it checked?
A receipt: the bill, its period, the UsageSummary and interval data read, the URDB record, the difference, the action, who approved, and when. Bills that matched are recorded as matched, with the tolerance that applied.
Does it change a payable or send a dispute on its own?
No. The vendor bill in NetSuite changes only after approval, once. A dispute leaves as a draft for a person to send; the operator has no channel to the utility.
Ask about Bill Reconcile

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.