Upload certificates data: Inventory and transactions

This article explains what certificate data needs to be uploaded into the Granular Energy platform, why each data type is needed, and how to get it in – whether through an automated registry API connection or a manual file upload.

What is this about?

There are three types of data the platform requires to be in sync with your certificates registries data:

Registry accounts — a short description of which account holders in which registries you own
Certificate holdings (inventory) — the balance of EACs in each account
Certificate movements (transactions) — all inbound and outbound movements for your accounts, including issuances, transfers, and cancellations.

The certificate inventory and the transactions are always kept in sync as a pair: inventory (the balance at a point in time) and transactions (the movements that produced it). The platform requires both together, because — like any accounting system — a balance is only meaningful if you can trace how it was built up, and is double-checked for any discrepancies or missing transactions.

The three data types

1. Registry account holders

Before any certificate data can be uploaded, the platform needs to know your registry account holder details. This is the first setup step.

Registry account holders are set up manually in the platform under Certificates → Registry accounts → Add an account holder. For each account holder you need to provide:

The registry it belongs to (e.g. OFGEM, HKNR, ERCOT)
Your account holder identifier and name (optionally) in that registry

This only needs to be done once per account holder. Accounts or sub-accounts don't need to be manually added since these will be created dynamically through the fields in the other files provided.

2. Certificate holdings (inventory)

Your inventory is the balance of EACs currently held in each registry account — how many certificates you have, by asset, technology, country of origin, and vintage period.

The inventory file is always uploaded together with the transactions file (see below).

The certificate holdings can be extracted out of any EAC registry.

If you have several accounts or sub-accounts in different registries, we require a single export of all accounts per registry and account holder.

3. Certificate movements (transactions)

Transactions are the complete log of all EAC movements in and out of your registry accounts — issuances, inbound transfers from counterparties or generators, outbound transfers to buyers, cancellations etc. This is the most fundamental piece of certificate data: the platform is transaction-first, deriving all inventory and position views from the transaction history.

Transfer files can be exported from any registry.

The platform validates that the total inventory above and the transfer data are consistent with each other — the transactions must fully explain how the inventory was reached. If your inventory shows 10,000 MWh in a given account, the transactions must account for every MWh that got it there.

Every inbound transaction (a received EAC transfer or issuance) needs to go through a reconciliation step in the platform before the corresponding inventory becomes allocatable. This is where you link the incoming certificates to the contracted supply volumes they belong to — ensuring nothing is double-counted. See the article Inbound transactions reconciliation - mapping received certificates to contracted supply

Cancellation and outbound transfer transactions are uploaded the same way as other transactions. Once uploaded, they are used in the allocation finalisation workflow to permanently associate specific certificate bundle IDs with a delivered allocation.

For the first upload (during onboarding): provide a starting inventory snapshot and, optionally, any transactions that occurred before the snapshot date. The platform will create "initialisation" transactions per account to account for any inventory that isn't explained by uploaded historical transactions.

Subsequent uploads: provide an updated inventory snapshot and all incremental transactions since the previous upload. Both files must be submitted together each time. It is perfectly fine to upload the same transaction again (as long as its properties are the same) so its usually best to provide overlapping histories of transactions.

How data gets into the platform

Automated: registry API connections

Granular Energy provides a single interface for all of your registry interactions. We provide direct API connection to the most used EAC registries. This allows you to automatically keep your certificate data synchronised — pulling inventory and transaction data at regular intervals (such as every day) without requiring any manual effort. This is strongly preferred for production use, as it eliminates the risk of gaps, delays, or formatting errors.

Alternatively for registries that do not offer direct API connection, we have alternative data ingestion pipelines that enable efficient data synchronisation.

Manual: CSV file upload

Where an automated connection is not yet available or to test new processes, the Granular Energy Technical Solutions team will support in building a flow to ingest certificate data via CSV. Contact your Customer Success Manager to set this up.

Tips & things to know

Inventory and transactions must be submitted together. Uploading one without the other will cause a validation error. In the case of automated updates, where the inventory balance hasn’t changed, it can be uploaded again with an empty transaction file.
Reconcile inbound transactions before allocating. Certificates from newly uploaded inbound transactions are not allocatable until they have been reconciled against a contracted supply volume. See: How to reconcile inbound registry transactions.
Certificate IDs matter for cancellations. For most transactions, uploading volume data (MWh) without individual certificate IDs is sufficient. However, for cancellation transactions specifically, including certificate bundle IDs allows the platform to display them in customer PDF reports — which is important for audit and compliance purposes.
Update frequency matters. For active portfolios, aim to keep certificate data in sync at least weekly, ideally daily — more frequently if your trading or delivery activity is high. Stale data means your position views and allocation workflows are working with incomplete information.
For questions or support, contact support@granular-energy.com