GHG accounting software starts with Scope 1 and Scope 2 data collection

GHG accounting software can calculate and report emissions only after an organization supplies usable activity data. For many companies, part of that foundation is spread across electric bills, natural gas statements, fuel invoices, shared folders, email attachments, and manually maintained spreadsheets.

The central challenge is not simply finding a number labeled “usage.” Teams must identify the correct facility, account, meter, fuel type, unit, and reporting period. They also need a reviewable connection between each structured value and its source document.

A controlled data-collection process gives sustainability teams a stronger foundation for Scope 1 and Scope 2 calculations. It also creates a dataset that finance and facilities teams can use for cost analysis, reconciliation, and operational reporting.

What GHG accounting software needs from source records

A GHG inventory generally combines activity data with the emissions factors and calculation methods selected by the reporting organization. GHG accounting software may manage those calculations, methodologies, organizational boundaries, approvals, and disclosures.

Before those functions can work, the software needs consistent activity records. For utility- and fuel-based sources, a useful record commonly includes:

• Facility or reporting entity
• Service address
• Utility provider or fuel vendor
• Account and meter identifiers
• Utility or fuel type
• Billing or service period
• Consumption value
• Unit of measure
• Cost and line-item charges
• Original source document
• Review and approval status

These fields answer different control questions. The facility and service address establish where consumption occurred. The service period determines when it belongs in the inventory. The unit controls how the activity value can be used in a calculation. Source evidence allows a reviewer to confirm what was reported on the original bill.

A monthly total without this context may be difficult to allocate, normalize, or defend. It can also lead to errors when invoices contain multiple meters, overlapping periods, adjustments, or several values using similar labels.

Scope 1 data available from bills and invoices

Scope 1 covers direct emissions from sources owned or controlled by the reporting organization. Utility and fuel documents can provide activity data for some Scope 1 sources, particularly stationary combustion.

Examples include:

• Natural gas consumed at a facility
• Propane delivered for on-site equipment or heating
• Fuel oil used in boilers or generators
• Diesel documented through purchased-fuel records

Natural gas statements may report consumption in therms, CCF, or MCF. Fuel invoices may use gallons, liters, or another delivery unit. The original unit should be retained, and any normalization should be controlled and documented.

Utility bills do not provide a complete Scope 1 inventory. Mobile combustion, refrigerant leakage, process emissions, and other direct sources may require fleet systems, maintenance logs, purchase records, operating systems, or specialized environmental data. A sound collection design therefore maps each emissions source to its actual system of record rather than treating utility bills as a universal source.

For bill-based Scope 1 inputs, teams should capture at least:

Cost can also be useful, but it should not be mistaken for physical consumption. A price change can increase spend without increasing fuel use. Whenever possible, emissions calculations should use the physical activity fields required by the organization’s selected methodology.

Scope 2 data available from utility records

Scope 2 covers indirect emissions associated with purchased energy. Electric bills are a common source of Scope 2 activity data, while invoices for purchased steam, heat, or cooling may also contain relevant consumption records.

Electricity statements can be complex. A single document may include:

• Several meters
• Multiple kWh values
• Demand measured in kW
• On-peak and off-peak periods
• Estimated and actual meter reads
• Net-metering credits
• Adjustments from earlier periods
• Taxes, riders, and other charges

For emissions accounting, electricity consumption and demand are not interchangeable. Demand describes the rate at which electricity was used, while consumption represents energy used over a period. Both can matter for energy management, but a GHG workflow must identify the activity field required by its calculation method.

Scope 2 accounting may also require information that is not contained in the utility bill. Depending on the organization’s methodology, teams may need grid geography, supplier information, contractual instruments, renewable energy documentation, or custom emissions factors. Those inputs should be managed alongside bill-derived consumption rather than inferred from a charge description alone.

A practical collection record for purchased electricity should preserve:

1. The consumption exactly as presented on the bill.
2. The stated unit and service period.
3. Facility, account, and meter relationships.
4. Separate meter-level records when one bill covers multiple meters.
5. Adjustments or credits as distinct line items.
6. A reference back to the page or bill evidence supporting each value.

That structure allows downstream GHG accounting software to apply the organization’s chosen Scope 2 methodology without relying on a manually retyped monthly total.

Why spreadsheet-based collection becomes difficult

Spreadsheets can be workable for a small and stable set of accounts. The process becomes harder to control as facilities, providers, document formats, and reviewers multiply.

A common manual workflow looks like this:

1. Bills arrive by email or are downloaded from provider portals.
2. Files are saved in local folders or a shared repository.
3. Someone opens each document and copies selected values into a spreadsheet.
4. Another person consolidates workbooks across facilities or business units.
5. Sustainability staff investigate missing values and unexpected changes.
6. The final dataset is imported into a reporting or carbon accounting system.

This workflow creates several control problems.

Field interpretation varies. One person may record total usage, while another records a meter subtotal. Similar-looking fields can have different meanings in the context of the bill.

Lineage is easily lost. A spreadsheet value may not include a direct reference to the original file, page, meter, or line item.

Exceptions are handled outside the process. Questions are resolved through email or chat without a durable review status.

Portfolio changes increase workload. Adding facilities introduces more accounts, providers, units, and expected monthly statements.

Corrections are difficult to propagate. A revised bill or mapping change may require updates in several workbooks and downstream reports.

Automation does not remove the need for controls. It moves those controls into a repeatable intake, validation, review, and approval process.

A controlled Scope 1 and Scope 2 collection workflow

An effective workflow separates document handling from emissions calculation. This makes it easier to identify whether a problem originated in the source record, extraction process, facility mapping, or calculation methodology.

1. Define the reporting boundary and source register

List the facilities, entities, utility accounts, meters, and fuel sources expected within the reporting boundary. Assign an owner to each source and record how often supporting documents should arrive.

The source register can be used to distinguish a true zero-consumption period from a missing bill. It also helps teams identify new and closed accounts during portfolio changes.

2. Centralize document intake

Collect bills and invoices through controlled channels such as email intake, file upload, shared folders, or APIs. Preserve the original file instead of retaining only a transcribed value.

Consistent intake reduces the need to search inboxes and folders during reporting or assurance preparation.

3. Extract bill-native fields

Capture the values presented on the document before applying emissions calculations. For utility records, this can include facility, service address, account, meter, service period, usage, demand, rate details, charges, taxes, and totals.

Line-item extraction is important when a bill includes several meters, utility types, or adjustments. A single invoice total does not provide enough detail to determine which activity belongs to which reporting record.

4. Normalize without discarding the original value

Map provider-specific fields into a consistent data model. Normalize facility names, utility types, dates, and units where required, but retain the bill-native value and unit for traceability.

For example, a standardized dataset may store a normalized natural gas unit while preserving the therm, CCF, or MCF value printed on the source statement.

5. Run validation checks

Validation rules can identify records that deserve attention before handoff. Useful checks include:

• Missing pages or required fields
• Duplicate bills
• Overlapping or unexpected service periods
• Gaps in expected monthly statements
• Unit mismatches
• Totals that do not reconcile
• Unusual usage, demand, or charge values
• Facility, account, or meter mapping conflicts

A flag should prompt review rather than automatically establish that the source document is wrong. Seasonal operations, estimated reads, catch-up bills, and tariff changes can all produce legitimate variances.

6. Review ambiguous records

Some documents require human interpretation. A reviewer should be able to inspect the source evidence, correct a field when necessary, and record the disposition of the exception.

If a provider repeatedly uses the same unusual layout, custom extraction logic or a custom schema can be applied to that bill family. This turns a recurring manual interpretation problem into a defined data rule while retaining an exception path for malformed or changed documents.

7. Approve and publish downstream

After review, send structured records to the organization’s GHG accounting software, sustainability platform, analytics environment, or finance system. Include source references and review status with the exported data when the downstream workflow supports them.

This handoff boundary matters. Data extraction prepares activity inputs; the GHG accounting system applies emissions factors, calculation rules, inventory boundaries, and reporting logic.

Where Parsepoint fits in the GHG accounting stack

Parsepoint is not an end-to-end GHG accounting or carbon accounting platform. It focuses on the document intake and data-preparation layer that comes before emissions calculation and disclosure.

Parsepoint can process electric, natural gas, and water utility documents from native PDFs, scans, email attachments, uploads, and portal exports. It turns bill content into structured records that can include:

• Facility, account, service address, and meter details
• Billing and service periods
• Electricity and natural gas usage
• Demand and meter readings
• Rates, tariffs, taxes, riders, and line-item charges
• Provider-specific fields present in the document

Extracted values remain linked to source evidence for review. Parsepoint can also flag missing pages, duplicates, period mismatches, unusual charges, and fields that could not be interpreted. Reviewers can edit ambiguous values or request an adjustment to custom extraction logic.

Validated records can then be exported to sustainability reporting, GHG accounting, analytics, AP, or other downstream workflows. Parsepoint does not replace the organization’s emissions methodology, emissions-factor governance, inventory controls, or final reporting platform.

This division of responsibilities is useful when an organization already has GHG accounting software but still depends on manual utility data entry to supply it.

How to evaluate software for this workflow

The right software design depends on where the current process breaks down. Some organizations need a complete carbon accounting system. Others already have calculation and disclosure tools but need a more controlled way to prepare activity data.

When evaluating a workflow, ask:

Can it preserve source-level evidence?

Reviewers should be able to move from a structured value back to the document that supports it. A database value without source context may simply reproduce the traceability problem previously found in spreadsheets.

Can it represent multiple meters and utility types?

One bill may contain multiple meters or a combination of electricity, gas, and water records. The data model should not force all activity into a single invoice-level total.

How are exceptions handled?

Look for explicit review states, editable fields, validation flags, and a record of reviewer action. “Automated” should not mean that ambiguous values pass downstream invisibly.

Does it distinguish extraction from calculation?

The system should make clear which values came from source documents, which were normalized, and which were calculated later. This separation supports troubleshooting and governance.

Can it accommodate provider-specific fields?

A standard schema is useful for reporting, but some providers include fields or charge structures that require custom handling. The workflow should accommodate those differences without abandoning consistency.

Can validated data move into existing systems?

Determine what output format, field mapping, source reference, and approval status the downstream GHG accounting software requires. Export requirements should be defined before building the intake process.

Build the data foundation before automating calculations

GHG accounting software is only one part of the reporting workflow. Scope 1 and Scope 2 calculations depend on activity data that is complete, correctly mapped, normalized, reviewed, and connected to evidence.

For utility- and fuel-based sources, the practical starting point is a source register and a controlled monthly process: collect documents, extract bill-native fields, validate the records, resolve exceptions, approve the data, and publish it to the calculation environment.

This approach does not eliminate professional judgment. It gives sustainability, finance, and facilities teams a clearer dataset on which to apply that judgment—and a traceable path back to the documents behind each reported input.