First Aid Queue

Feeling uncertain? Take a look at the common questions below, you might find your answer.

You are here: / / Frequently Asked Questions

G-REX

G-REX is a next generation registry solution using a Registry as a Service (RaaS) model.

The key feature of G-REX is that it  adapts to the requirements of all energy carriers with a single registry solution and adheres fully with the changing requirements of the CEN 16325 and other European legislation and industry standards.

Key reasons to choose G-REX as the platform for new energy carrier GO systems include:

  • Running on service model without upfront investments.
  • Guaranteed compliance with all European regulation and standards as part of the service without extra cost or work in defining complex change requests.
  • A highly customizable product, which caters the needs for all energy carriers either in a single domain within a country or in separate domains running on the same platform.
  • Cloud native platform, which automatically scales to the need of the specific domain and in which all functions can be accessed using APIs.
  • Fast and modern user interface which allows excel-like filtering and sorting of all data.

To book a demo session for G-REX, just go to our contact page and fill in the details in the form bellow and hit send! we will contact you according to the wishes you filled in the form.

G-REX is built API-first, which means everything that can be done via G-REX UI, can also be done by consuming APIs, and much more. The APIs are well-documented, self-descriptive and easy to use:

  • Certificate Creation API: https://grexapi.grexel.com/certificatecreationapi/v1/
  • Management API: https://grexapi.grexel.com/managementapi/v2/
  • Master Data API: https://grexapi.grexel.com/masterdataapi/v2/
  • Private Reports API: https://grexapi.grexel.com/privatereportsapi/v1/
  • Public Reports API: https://grexapi.grexel.com/publicreportsapi/v1/
  • Transaction API: https://grexapi.grexel.com/transactionapi/v1/

New to G-REX?

  1. For first login, click the link in the email you received.
    you will be     redirected to the G–REX login portal to set up a password and multifactor
    authentication. Set up your password.
  2. You will be redirected to Azure login page and prompted to enter credentials. Enter your credentials and click Sign In.
    • Note: The Email address for the login will always be  the same as the email to which the invitation email was sent.
  3. After entering the credentials, you will be prompted for multi–factor authentication (MFA). This requires the Microsoft Authenticator application to be downloaded onto your mobile device.
    • Note: Multi-factor authentication means that you must verify the login using a mobile phone connected to the application during the first login
  4. As part of the first–time MFA set up, you will be prompted by the G–REX login page to scan a QR code.
    • In the Microsoft Authenticator app:select “Add Account” –> “Work or school account” –> “Scan a QR code”.
    • Scan the QR code on your screen using your device’s camera.

After successfully adding the account, it will be visible in the home page of the app. Clicking on the account reveals a one–time code to be used during the MFA process.
This code refreshes automatically every 30 seconds.


Note: This code will be requested by G–REX for future log in attempts, after the G–REX username and password are entered.

IMPORTANT!

Once you have established a connection with the Microsoft Authenticator App we highly recommend that you back up your account in the Autheticator App. you can find the instructions on how to do so here.

  • In order to connect from a new device,
  • In case that you did not back up your account, or the restoration of the account onto your new device did not succeed for any reason, the authentication connection needs to be reset in order to register on your new device. Request an Authenticator Reset from your Issuing body.

Important: Remember to backup your Authenticator App account.

In the case of a forgotten password:

1. Click Login on public page.
2. Click Forgot your password
3. Follow the steps of the Azure AD password reset flow

The user manual is available on every G-REX screen. Once logged in, press the (Information Icon) on the bottom left of the screen to open it in PDF.

Start and end times are exclusive, which means that the start date time of the new instance (license, organization etc…) should be set as the same as the end date time of the previous instance. Most commonly the change occurs on the first of the month at 0.00 hour. For instance, if a production device license or role changes at 1.2.2022, then end date time of the first should be set as 1.2.2022 0.00 and start date time of the second should set equally 1.2.2022 0.00.

In Production Device registration, selecting “use start date time for all start date times” on the general tab will automatically populate the same start date time for other tabs.

To avoid conflicts, please use full days and always select time as 0.00.

Standard: Most commonly standard level separation is used for certificates of different energy carriers (electricity, gas, heating and cooling). Certificates of different standard cannot be held on same certificate accounts. Account Holders can only possess certificates related to the standard they are registered for. Except for a few exceptions there is only 1 standard per domain.

Trading Scheme belongs to a standard and is the “name” of the certificate, most commonly guarantee of origin (GO). In some cases, there can be several trading schemes such as GOs and Independent Criteria Schemes. Transfer of certificates is not restricted by the Trading Scheme, meaning an Account Holder without a given Trading Scheme can transact with certificates of that Trading Scheme. However, an Account Holder needs to have the relevant Trading Scheme active to be issued certificates with that Trading Scheme.

License: License is related to different certificates under a standard. The most common case is the separation of GOs between RES and High-Efficient Co-generation. The various licenses assist the user in knowing what the mandatory and optional fields in each case are. For example, when selecting the “renewable” license the user is not bothered with the fields only relevant for High-Efficient Cogeneration. The license name is not visible in the certificate and the sole purpose of multiple licenses is to assist the issuing body to issue certificates with correct information.

Production Devices

After first issuing, several PD data fields are locked. This is to preserve an audit log for historical information. Changing the information of a production device is done by adding new roles or licenses and ending previous ones. Once issuing is made it is no longer possible to delete licenses or roles, but only to edit the end time, which allows new roles and licenses to be created after that.

Changing the technology and energy sources of a Production Device is not possible after first issuing.

There are typically 2 EECS Licenses:

  • Electricity Renewable EECS V71
  • Energy Certificate EECS

The first license is the one to use by default as it includes only the mandatory fields for renewable EECS GOs.

The second license is more flexible and includes all possible fields for EECS GOs. This enables the issuing body to issue GOs for high-efficient co-generation and non-renewable electricity. When doing so, the Issuing Body should check which are the mandatory fields in each case.

Editing a license is not possible after meter readings have been created for the license. Please end the license and create a new one with the same start date time as the previous end date time. “Copy License” button automatically populates information of the previous license to the next one as basis.

Changing the ownership of a production device license, will determine to what organization the certificates are to be issued to unless also aggregation information is given.

Changing the ownership can be done by setting an end date to the license and adding a new license where the new organization will have ownership of the license. The start date of the new license should be set to the same end date time as the previous license.

Please note that changing the ownership does not change the registrant organization of the production device, which is managed on the organization tab of the PD.

To add a registrant to a plant, one first must set an end date and start date to the following:

  1. previous registrant
  2. meter
  3. License (where the current registrant is an owner).

Then save the production device. The previous registrant, meter and license end date should be set the same as the new registrant, meter and license start date. The change is needed on these 3 tabs because the old meter and license are “connected” to the previous registrant and therefore need to be restarted “under” the new registrant.

Please note that: The new meter can have the same grid reference as the old meter if it starts on the end date of the previous meter (which would make it unique as the only active meter with this reference).

One can add a new meter as long as the Gird reference is unique in the whole domain.

To change a meter, one would need to set an end date to the old meter and set the start date of the new meter to be the same as the end date of the old meter. The new meter can have the same grid reference as the old meter if it starts on the end date of the previous meter (which would make it unique as the only active meter with this reference).

General tab: Start date of the device in the registry. Should be set as the first date for which the device can receive certificates for its production. Any other start date set for the device cannot be prior to this date.

Organization tab: Generally use the same as start date on general tab

The first organization role start date of a device should be the same as the start date of the device. If there are changes in the roles, the prior role should be ended and new one started accordingly. Use the same date time as end date time of the previous organization and start date time of the next organization.

Please Note:

  • It is only possible to create a license at a period during which there is a Registrant.
  • A Production Device must have an active Registrant at the current moment. It is not possible to create a production device for which the Registrant period starts in the future or has already ended.

 

Meter tab: Generally same as start date on general tab

The first meter start date should be the same as the start date of the device. If the meter changes for one reason or another, the prior meter should be ended and new one started accordingly. Use the same date time as end date time of the previous meter and start date time of the next meter. It is only possible to create or receive meter readings for a period at which there is a meter.

License tab:

  • Start date: The first license of a device should start at the same time as the device starts. It is not possible to create or receive meter readings or issue certificates for periods not included in a license.
  • End date: If the information of the license changes, the existing license should be ended and a new one started. The start and end datetimes of the previous and following licenses should be set as the same. Note that meter readings and declarations cannot run across several licenses and therefore the license switch time should be the set like meter reading end time.
  • For example if the license ends after January 2023, the end time of the existing license and the start date of the new license should be set at 1.2.2023 0.00.
  • Operational date: The time at which the operation of the device began (not in relation to GOs but in relation to energy production).

A grid reference is connected to a meter, and it is the unique identifier of the meter. The Issuing Body should use its own coding here so that when it sends Meter Readings the values are associated with this reference.

The naming convention of the grid reference is defined by the Issuing Body.

Account Holders, Users and Accounts

Account Holder = Company = Organization

Account = an individual certificate account within that organization in which certificates are held. An organization can have multiple accounts.

User = An individual person (employee) of an Account Holder. A single user may have rights to multiple Account Holders.

Organization start date defines when the organization starts to use G-REX. Organization can receive certificates to their account only after this date. No Organization related start date can be prior to this date.

Organization type start date: Generally, use the same as Organization start date.

An organization can have several Organization Types at the same time. Organization type is in most cases only meta-data for the Issuing Body. Please note that some organization types do not have certificate accounts (such as Registrar, non-account holder account, Measurement Body). Please see specific instructions in Table 8.2 1 Organization data properties of the IB manual.

Trading Scheme start date: Generally, use the same as Organization start date

Organization cannot be issued certificates of a given trading scheme prior to the start date. In the rare event that the trading scheme of an organization changes, the previous scheme should be ended and the new one started accordingly. An organization can have several trading schemes at the same time, but most commonly there is only 1: GO.

The start date of a user is automatically set to the time when the user is created.

The process is exactly like creating a user for the first time. After the user is created in a new organization, the user can navigate between the organizations through the “change organization” function.

Login email relates to the email the user uses for logging in and is necessary in creating a user.

Email connected to an organization role is not mandatory but is asked for contact information.

If an Account is selected as Public, other Account Holders within the domain may select it as a recipient of certificate transfers in the transfer dialogue. Other Account Holders will not see any other details of a Public Account besides the Account Name and Number as well as the Account Holder to which it belongs to.

A Non-Public Account is only visible for internal transfers between own accounts of the Account Holder.

In case of transfers from another domain, only your default account is selectable as target account regardless of whether other accounts are marked as public.

Marking an Account as public does not mean that other Account Holders would be able to see any contents of it other than the name and number of the account.

Cancellations

Energy Suppliers

  • Energy supplier cancelling to prove the origin of a specific electricity product sold to final consumers (e.g. “Ultimate Greenness”)
    1. Cancellation Purpose: “Electricity product: Ultimate Greenness”
    2. Name of Beneficiary: name of the Energy supplier in question, e.g. “Powerhouse”.
    3. This case also includes the situation where the Energy supplier is selling electricity from a specific energy source to a group of customers, without an “actual” product name, e.g under the name: wind-electricity.
  • Energy supplier cancelling for an end consumer according to a specific contract (e.g. “Contract XYZ”):
    1. If the contract is for the bundled supply of electricity and its origin:
      • Cancellation Purpose, e.g.: “To prove the energy source of sold electricity as wind energy without public support. Contract Reference: XYZ.”
      • Name of beneficiary: name of the Energy supplier in question, e.g. “Powerhouse”.
    2. If the contract is for proving the origin of electricity not necessarily sold as part of the contract:
      • Cancellation Pupose, e.g.: “To prove the energy source of consumed electricity as solar energy and from a plant commissined less than 5 years ago. Contract Reference: XYZ”
      • Name of beneficiary: name of the End-consumer in question, e.g. “Associated Computer Company Limited”.
    3. The difference between the two cases (a and b) above is small. Often the chosen option can be either and in that case the decision should be taken based on who would you like to choose as the beneficiary: the energy supplier or the end-consumer.

End Consumers

  • End consumer cancelling to prove the origin of consumed electricity
    • Cancellation Purpose, e.g.: “To prove the energy source of consumed electricity as bioenergy.”
    • Name of Beneficiary: name of the End-consumer in question, e.g. “Associated Computer Company Limited”.

Third Party Service Providers

  • Service providers making cancellations on behalf of Energy Suppliers or End Consumers should follow the rules given above for Energy Suppliers and End Consumers respectively. A service provider never marks itself as the beneficiary unless cancelling GOs for its own electricity consumption.

The concept of cancellation is extremely important in the process of energy certification because, in the same way as issuing of certificates detaches the origin of the electricity from the physical electricity, cancellation attaches the origin back to a certain sold or consumed electricity (see figure at the bottom of the page).

That is why you need to fill in a number of data fields (listed below) in order to make sure this cancellation is valid only for a specific electricity lot sold/consumed and cannot be used several times. The fields are:

  1. Country of consumption. This is the country where the electricity is sold or consumed. Please note that according to EECS rules, you cannot cancel certificates to any other EECS country, because in this case you should first export the certificates to the registry of that country and only after that the certificates can be cancelled. In other words, “ex-domain cancellation” is only allowed when a certificate cannot be moved between two countries due to technical restrictions, which is not the case for any two EECS countries.
  2. Name and type of beneficiary. There are basically two alternatives for the beneficiary of a cancellation: a) the seller or b) the consumer of the electricity. Hence, the type of beneficiary is either “energy supplier” or “end-consumer” and, according to Grexel’s recommendation, the cancellation should be able to distinguish whether the origin was attached to sold or consumed electricity. Hence:
  • The energy supplier is the beneficiary when the origin is attached to sold electricity, i.e. green label, electricity product, mix or unique agreement to certain customer. It is the supplier that does the “greening” and sells electricity. Naturally the type of the beneficiary should in this case be “energy supplier”.
  • The end-consumer is the beneficiary when it has purchased the physical electricity elsewhere and the “grey” electricity is just greened by the end-consumer or by someone else on its behalf. This is the case if e.g. a large consumer buys its electricity directly from an exchange and this electricity is then greened with certificates, or if a producer-consumer uses certificates for its own operation. Naturally the type of the beneficiary should in this case be “End-consumer”.
  • If a trader, broker or consultant is making the cancellation on behalf of an energy supplier or an end-consumer, the same rules as above apply.
  1. Location of beneficiary. This field further identifies the beneficiary in providing for example geographical area, department, address, or whatever information is needed to uniquely identify the electricity for which the cancellation is made.
  2. Usage category. In normal cases this is always “Disclosure”. Please do not use other categories unless you are confident that it is the right one.
  3. Consumption period. This refers to the first and last dates of the consumption of the sold/consumed electricity to which the origin is attached. Normally, these fields refer to a calendar year so that if the certificates are cancelled for disclosure of 2012, the consumption period is the whole year 2012.
  4. Cancellation purpose. In the free form field you should give any further information that is needed to make the cancellation unique. It might be name of product, label, client, contract dates or numbers etc. It is important to look at the cancellation as a whole and make sure that an external auditor is able to use the cancellation statement to verify that the same statement cannot, for example, be used for several clients.

At the beginning of each year electricity suppliers are faced with a common set of problems… How do I close my electricity product portfolio for last year properly? What do I disclose to those consumers not purchasing a specific electricity product? What is the total energy mix of my electricity sales? If these sound like questions you are struggling with, you might want to read this FAQ entry carefully!

First, let’s define a few concepts:

  • Electricity disclosure: The process where electricity suppliers disclose to final customers the energy source(s) and CO2 and radioactive waste content of the supplier’s electricity.
  • Electricity Product: Electricity which is sold to customers with predefined claims over the energy source, environmental impacts or other generation attributes.
  • Residual Electricity: The electricity that a supplier sells to customers who are not purchasing an electricity product.
  • Supplier Mix: The total mix of energy sources and environmental impacts of a supplier’s electricity sales during a year.

All set. Here’s how it would go for 2021:

  1. Determine the volume to be disclosed:

After the end of 2021, determine total electricity sales of 2021 as well as the volume and type of each electricity product sold in 2021.

  1. Make the cancellations:

The RE-DISS Best Practice Recommendation for the deadline for making cancellations for electricity sales of 2021 is March 31st 2022. Countries may differ in how they choose their deadlines, but most EECS countries have selected the date recommended by RE-DISS.

Before the end of March 2022 you are required to perform cancellations of GOs matching the type and volume of electricity products you have sold during 2021. The cancellations can be made anytime between 1.4.2022 – 31.3.2022 [1], but since the sales figures are only known after the end of the year, the beginning of the year often marks a significant cancellation peak for previous year disclosure.

Cancellations for products are required, but, voluntarily, you may also make cancellations to influence the energy mix of your customers who are not purchasing a specific product, i.e. those buying your own “residual electricity”. This will, naturally, also improve your supplier mix.

  1. Determine the 2021 residual electricity and supplier mix of your company:

In the previous step, we already closed our books regarding electricity products sold in 2021, but still the energy mix of residual electricity of 2021 needs to be determined. There are three cases of how this can be done depending on volume of GOs cancelled for this purpose:

  • If no GOs cancelled for the residual electricity: take directly the national residual mix of 2021 as published by your domain’s authority in the end of May 2022.
  • If GOs are voluntarily cancelled for part of the volume of residual electricity sold: Determine the volume of residual electricity sold during 2021 (e.g. 500 GWh). Determine how many GOs you have cancelled for this purpose before 31.3.2022 (e.g. 50 GWh). Take the remainder (450 GWh) from the national residual mix of 2021 according to the shares of different energy sources and content of CO2 and radioactive waste in the national residual mix. Combine the intake from the national residual mix (450 GWh) with the GOs (50 GWh) (including environmental impacts) that you have cancelled for this purpose.
  • If GOs are cancelled for the entire sales of residual electricity: The residual electricity is according to the GOs cancelled for this purpose. For example if all the GOs cancelled are from renewable energy sources, the residual electricity is 100 % green.

The supplier mix can be obtained by adding the origin of electricity products sold into the residual electricity of the supplier. Often the residual electricity and supplier mix of year 2021 needs to be published and attached into bills by the supplier starting from 1.7.2022, but this might depend on your national legislation.

[1] To facilitate the calculation of the residual mix, it’s recommended not to perform cancellations for year 2021 electricity consumption before 1.4.2021, although this is not forbidden.

Changes to schema by AIB

Below are the changes that were made to the fields due to the switch to the new schema version from AIB (v80).

The biggest change in the new version of AIB schema is that in the v71 there was only one Energy carrier Electricity, and for that we used standard EECS. In v80 there are three energy carriers: Electricity, Energygas and Hydrogen. According to AIB Rules, those energy carriers should not be mixed in same transfers and hence we have implemented separated standards for those as shown below:

  • EECS_ELECTRICITY
  • EECS_ENERGYGAS
  • EECS_HYDROGEN

In addition, the new version v80 is bringing couple of more information fields for the certificates and clarifying a bit the naming and datatypes of the information fields. The details can be found in the end of this email.

The v71 and v80 schemas including conversion from v71 to v80, are described by AIB in the document: https://www.aib-net.org/eecs/subsidiary-documents. According to the AIB, while making the change, the existing v71 certificates were converted to v80 with the rules set in the document.

See below the changes (HEC in below refers to High Efficiency Cogeneration certificates):

NEW NAME OF THE ATTRIBUTE/NEW ATTRIBUTE VALUE:  
ELECTRICAL_CAPACITY CAPACITY_ELECTRICAL Field Namekeyword change.
MECHANICAL_CAPACITY CAPACITY_MECHANICAL Field Namekeyword change.
THERMAL_CAPACITY CAPACITY_THERMAL Field Namekeyword change.
AMOUNT_PRIMARY_ENERGY_SAVED COGENERATION_PRIMARY_ENERGY_SAVED_AMOUNT Only for HEC certificates Field Namekeyword change.
PERCENTAGE_PRIMARY_ENERGY_SAVED COGENERATION_PRIMARY_ENERGY_SAVED_PERCENTAGE Only for HEC certificates Field Namekeyword change.
OVERALL_PRIMARY_ENERGY_SAVINGS COGENERATION_PRIMARY_ENERGY_SAVINGS_OVERALL Only for HEC certificates Field Namekeyword change.
USE_OF_HEAT COGENERATION_USE_OF_HEAT Only for HEC certificates Field Namekeyword change.
Value change:
a > COGENERATION_USE_OF_HEAT:A
b > COGENERATION_USE_OF_HEAT:B
c > COGENERATION_USE_OF_HEAT:C
d > COGENERATION_USE_OF_HEAT:D
USEFUL_COGENERATION_HEAT COGENERATION_USEFUL_HEAT Only for HEC certificates Field Namekeyword change.
ENERGY_MEDIUM ENERGY_CARRIER Namekeyword change. Value change:

Electricity > ENERGY_CARRIER:ELECTRICITY

Addition of new Energy carriers (depending on the domain):
ENERGY_CARRIER:ENERGYGAS

ENERGY_CARRIER:HYDROGEN
CO2_EMISSION_PRODUCED GHG_EMISSION_PRODUCED Only for HEC and Fossil certificates Field Namekeyword change. Field is not anymore compulsory for Fossil certificates (depends on Issuing body if it will be issued or not).
ABSOLUTE_CO2_EMISSION_SAVED ABSOLUTE_GHG_EMISSION_SAVED Only for HEC certificates Namekeyword change (GHG refers to Greenhouse gas, the new field GHG_EMISSION_PRODUCED_CALCULATION_METHOD is to define which method has been used for the calculation, if only CO2 or something else.
PRODUCT_TYPE PRODUCT_TYPE Value change from:
Source -> PRODUCT_TYPE:SOURCE
Technology ->  PRODUCT_TYPE:TECHNOLOGY
RADIO_ACTIVE_WASTE_PRODUCED RADIOACTIVE_WASTE_PRODUCED Only for Nuclear certificates Namekeyword change, datatype change from Integer to DECIMAL. Field is not anymore compulsory for Nuclear certificates (depends on Issuing body if it will be issued or not).
NEW ATTRIBUTES in v80 related to Electricity certificates:
New attribute CONVERSION_TAG New field for all certificates e.g.: CONVERSION_TAG:C01 All codes can be found from AIB Fact sheet 23 https://www.aib-net.org/sites/default/files/assets/eecs/facts-sheets/AIB-2022-EECSFS-23%20EECS%20Rules%20Fact%20Sheet%2023%20-%20Conversion%20tracking%20-%20Release%201.0.pdf
New attribute DISSEMINATION_LEVEL New field for all certificates e.g.: DISSEMINATION_LEVEL:2. All codes can be found from AIB Fact sheet 20  https://www.aib-net.org/sites/default/files/assets/eecs/facts-sheets/AIB-2019-EECSFS-20%20EECS%20Rules%20Fact%20Sheet%2020%20-%20Dissemination%20level%20of%20Output%20-%20release%202.0%20-.pdf
New attribute HIGH_EFFICIENCY_COGENERATION_CRITERIA_MET New field only for HEC certificates TRUE set for the HEC Certificates and for HEC LICENSES
New attribute CALORIFIC_VALUE_TYPE New field only for HEC certificates Possible values:
CALORIFIC_VALUE_TYPE:LOWER,
CALORIFIC_VALUE_TYPE:HIGHER
New attribute CALORIFIC_VALUE_UNIT New field only for HEC certificates Possible values:
CALORIFIC_VALUE_UNIT:MJ_PER_KG,
CALORIFIC_VALUE_UNIT:MJ_PER_M3,
CALORIFIC_VALUE_UNIT:MJ_PER_L
New attribute GHG_EMISSION_PRODUCED_CALCULATION_METHOD New field only for HEC and fossil certificates e.g. GHG_EMISSION_PRODUCED_CALCULATION_METHOD:E0100000000.
Defines which method has been used for the calculation of GHG Emissions, if only CO2 or something else. Refer Fact sheet 24 “Methodology GHG Methodology Reference”
New attribute ABSOLUTE_GHG_EMISSION_SAVED_CALCULATION_METHOD New field only for HEC certificates e.g.; ABSOLUTE_GHG_EMISSION_SAVED_CALCULATION_METHOD:E0100000000.
Defines which method has been used for the calculation of GHG Emissions saved, if only CO2 or something else. Refer Fact sheet 24 “Methodology GHG Methodology Reference”

Processes of the G-REX Sandbox

  • Contract Signing
  • Grexel creates 3 Account Holder organizations for the Client
  • Grexel creates 1 Root user for the Client with access to all three organizations.
    • The Client Root user may create additional users with selected rights and access to any or all the 3 organizations.
  • Grexel creates 5 Production Devices and 5 Certificate bundles for one of the organizations of the Client.
  • The Client may register new Production Devices via API or the User Interface of G-REX. Once created, the Client submits them for Grexel approval via the system.
  • The Client may create and submit new Meter Readings for active Production Devices registered for one of its organizations.
  • In case of multi-fuel device, the Client may create fuel declarations for active Production Devices registered for one of its organizations.
  • once a week, Grexel approves all Production Devices, Meter Readings and Declarations submitted by all Clients in the system.

Additional requests should be submitted via the Grexel support portal. These requests could include for example:

  • Creation of new organizations,
  • Additional instructions
  • Creation of certificates on behalf of the client
  • API support
  • Any other direct support needs

Additional requests are invoiced based on actual hours spent with 1/2h accuracy at a rate stated in the contract.

Couldnt find what you are looking for?

Go to our Support portal and fill in the form with your question or knowledgeable team will get back to you and help you with information where needed.

Go to our Support Portal and submit a request by filling in the form with the information required, and our team will handle it from there.

And remember the more precise the request is and the more details we have, the faster the solution comes!