Carbon fees, carbon rights and internal carbon pricing all convert carbon emissions into amounts, but their purposes and usage methods are different. If companies mix them together, they can easily make misjudgments on budgets, reductions, and claims.
Differences between the three
| Projects | Carbon Fees | Carbon Rights | Internal Carbon Pricing |
|---|---|---|---|
| Nature | Fees levied on specific emissions according to law | Emission reduction/removal quotas that can be transferred or written off | Management prices set by enterprises themselves |
| Price sources | Competent authorities and regulations | Market, project and quota quality | Regulations, markets, scenarios or reduction costs |
| Main uses | Compliance and policy reduction | Swapping, trading or climate contribution | Investment, budgeting, product and risk decisions |
| Whether payment must be made | Handled in accordance with the law when the conditions for collection are met | Purchased according to corporate needs | Does not necessarily form an external payment |
Carbon fee is the cost of regulations
Enterprises must confirm the collection objects, emissions, applicable rates, declaration period and preferential conditions in accordance with the regulations of the competent authority. Whether you need to pay a fee cannot be set by yourself, nor can it be replaced by an internal carbon price.
Carbon rights are quotas
Carbon rights are derived from specific emission reduction or removal projects and vary in quality, vintage and usage rules. The purchased quota will not automatically reduce the company’s own inventory emissions. When used, cancellation and information disclosure must be completed according to the purpose.
Internal carbon pricing is a decision-making tool
Enterprises can use shadow prices to evaluate future carbon costs, or charge carbon fees to internal units to form a carbon reduction fund. It allows high-emission scenarios to reflect the risks in financial analyses, and also allows the benefits of different abatement investments to be compared.
How to manage the three together?
Enterprises can first complete an emissions inventory to identify emissions and future costs affected by carbon fees; then use internal carbon pricing to incorporate risks into equipment, products and purchasing decisions; and only evaluate carbon rights based on strategies for remaining emissions that are difficult to eliminate.
Common misunderstandings
- Purchasing carbon rights does not mean paying carbon fees.
- Paying a carbon fee does not mean that a company has reached carbon neutrality.
- Internal carbon prices do not have to equal government rates.
- The low price of carbon rights does not mean that the quality is suitable for the company’s claims.
Putting the three in the same carbon cost map, but managing regulations, quotas and decision-making purposes separately, can avoid double counting and false claims.
Before comparing, first confirm what problem the company wants to solve.
Different systems may seem to use similar terms, but in fact they may serve regulatory compliance, information disclosure, verification, transactions or internal decision-making respectively. When choosing, you should not just ask which one is easier, but first confirm the external requirements, intended users, delivery period and whether verification is needed in the future.
It is recommended to use five judgment aspects
- Applicable objects: manage organizations, products, projects, supply chains or specific markets.
- Primary purpose: Quantification, disclosure, verification, regulatory compliance, or decision-making.
- Profile Boundary: Which companies, locations, life cycle or value chain activities are covered.
- Deliverables: Reports, statements, certificates, scores, declarations, or internal analyses.
- Ongoing Accountability: Whether annual updates, revalidations, tracking targets, or evidence preservation are required.
Do not create a separate set of profiles for each requirement
Enterprises should first establish a common organization, products, suppliers, activity data, attachments and audit basis, and then establish classification and output rules according to different systems. If each project collects data independently, multiple versions will easily appear during the same period, and the organizer will not be able to explain the differences.
Which situations require simultaneous use?
When regulatory, customer and disclosure requirements each specify different bases, companies may need to do so in parallel. At this time, a comparison table should be established to describe common data, unique requirements, boundary differences, and output formats, rather than requiring each department to fill it out repeatedly.
Common selection errors
- Thinking that the content can replace each other just because the names are similar.
- Compare only the number of clauses, ignoring customer or regulatory requirements.
- Choose tools first, then look back for management purposes.
- No assessment of data maturity and maintenance costs.
- Treat passing verification as the only indicator of system completion.
Self-check before making decisions
- Which one is a clear external requirement, and which one is an enterprise’s own choice?
- Is third-party verification, evaluation or reporting by the competent authority required?
- Can existing data support the required bounds and precision?
- Can the two systems share data and processes?
- Will there still be maintenance and update resources in the next three years?
There is not necessarily just one most suitable solution. If companies can establish a common underlying data, they can combine standards and tools for different purposes without having to start from scratch every time.
When companies choose a method, it is recommended to confirm four things in order
Start by identifying external requirements. Whether clients, authorities, parent companies, investors or verification agencies specify specific standards will directly affect the methods that can be used. If there is no mandatory designation, go back and evaluate the management problem that the company really wants to solve to avoid choosing the wrong tool because of similar names.
Next, confirm the management objects and boundaries. Some approaches focus on the entire organization, while others focus on products, value chains, projects, or specific disclosure situations. Depending on the boundaries, the required data, responsible units, and results usage will all change. When comparing, “what is counted, where it is calculated, and who uses the results” should be put on the same table, rather than just comparing the number of articles.
The third is to check the maturity of the data and resources. If an enterprise has not established basic inventory and data management and directly introduces more demanding methods, it may result in a lot of estimation and rework. You can complete the common foundation first, and then gradually increase the sophistication according to market demand. If multiple frameworks have common data, a design should be adopted to collect it once and output it in multiple ways.
Finally, consider verification and future expansion. A company may only need internal management now, but may face customer audits, public disclosures or third-party assurances in the future. Keeping records of sources, versions, assumptions, and approvals from the outset is much easier than reconstructing evidence afterward.
After comparing, how to make a choice that suits you?
Businesses don’t necessarily have to choose one or the other. If the two methods serve different purposes, a common data base can be established and corresponding results can be produced separately; if the two methods are highly overlapping, a set of main governance rules should be selected to avoid departments maintaining different versions. When making decisions, the five conditions of “necessity, data availability, implementation cost, external acceptance, and future scalability” can be used to evaluate, and the reasons for the choice should be recorded.
For companies that are in contact for the first time, the most important thing is not to adopt the most frameworks immediately, but to establish clear boundaries and traceable information first. When the common foundation is stable, adding new disclosure or verification requirements is usually just an adjustment to the output method; on the other hand, if the underlying data is confusing, even the most complete method will not be able to produce credible results.
