> For the complete documentation index, see [llms.txt](https://docs.enapi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enapi.com/pricing-and-tariffs/how-tariffs-work-on-enapi.md).

# How Tariffs Work on ENAPI

In OCPI, a **tariff** is the pricing a CPO applies to a charging session — per-kWh energy, per-hour time/parking, flat session fees, and any restrictions on when each component applies.

### How tariffs flow

1. The CPO publishes tariffs via the OCPI Tariffs module.
2. ENAPI stores tariffs and validates basic integrity (e.g., structure, currency, and elements) before making them available for downstream use.
3. CPOs associate tariffs to connectors via the `tariff_id` references published in the OCPI Locations module. Tariffs without a Location reference may exist, but they won’t be used for price display or CDR validations.
4. eMSPs receive tariffs during sync and show them to drivers.
5. Published tariffs feed the **Tariff Cost Consistency** validation on every CDR (see [Validation Rules Reference](/cdr-clearing/validation-rules-reference.md)).

{% hint style="info" %}
That last point matters: ENAPI uses the published tariff as the reference to independently calculate an **expected price** for a given CDR. If the tariff is inaccurate, out of date, or inconsistently applied across Locations, ENAPI will flag CDRs even when the CDR itself is “technically valid”.
{% endhint %}

### Price differentiation via partner-specific tariffs

In “plain” OCPI, tariffs are typically **bound to the connector**: a Location’s EVSE/connector references a `tariff_id`, and that tariff is what *all* connected receiving parties (eMSPs) will see for that connector. In other words: the OCPI object model is optimized for **one published price per connector**, not for negotiated, partner-specific pricing.

In practice, however, many CPOs run different commercial setups:

* Different prices per eMSP (or per market/channel)
* A main eMSP and multiple **sub-eMSPs** (white-label / reseller setups)

To support this while still staying interoperable with OCPI, ENAPI has developed a technical solution to **differentiate which tariff is exposed and applied per eMSP/sub-eMSP**, while keeping the underlying OCPI connector mapping consistent. This allows partner-specific price display and (critically) partner-specific cost validation against CDRs — without forcing CPOs to maintain separate “shadow” locations per partner.

#### Two ways to differentiate prices

ENAPI supports two models, depending on whether the CPO or ENAPI owns the pricing logic:

* [Partner Specific Tariffs CPO Managed](/pricing-and-tariffs/partner-specific-tariffs-cpo-managed.md) — your CPMS produces partner-specific tariffs and rates sessions per eMSP. ENAPI routes them.
* [ENAPI Managed Tariff Adjustments](/pricing-and-tariffs/enapi-managed-tariff-adjustments.md) — you publish one standard tariff; ENAPI applies discounts or surcharges per eMSP, sub-operator, or token group, and re-rates sessions and CDRs on your behalf.

Both approaches keep the same tariff IDs and OCPI Locations mapping, and work with OCPI 2.1.1 (using backported routing headers), 2.2.1, and 2.3.0.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.enapi.com/pricing-and-tariffs/how-tariffs-work-on-enapi.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.