> 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/cdr-clearing/how-to-handle-flagged-cdrs.md). # How to Handle Flagged CDRs When a CDR is flagged, the rule fired tells you *what* is off — but not *why*, or whether it's your problem or your partner's. This page is the decision guide. ### The general approach Every flagged CDR has the same set of questions behind it: 1. **Is the underlying session plausible?** Could what the CDR describes have actually happened — given the charger, the driver, the time of day, the duration? 2. **What does my contract say?** Many flags come down to thresholds that were negotiated at contract time — late-arrival windows, minimum session sizes, cost tolerances. 3. **Does either side have more context?** The eMSP's app may have driver-reported issues. The CPO's CPMS may have charger telemetry. Before disputing, check. From there, the rule that fired determines the specific questions. ### High energy, high cost, or long duration Often these flags fire together and represent the symptoms of one underlying problem. **Likely causes:** * Charger failure — the charger didn't release properly and kept metering. * Meter failure — the meter reported energy that wasn't actually delivered. * Session not stopped — the driver left, but the session didn't terminate cleanly. **What to check:** * **Plausibility.** Could the reported values happen physically? A 200 kWh session on a 22 kW AC charger would require 9+ hours; that's mechanically possible but worth scrutiny. A 500 kWh session in an hour on a 50 kW DC charger isn't. * **Driver dispute.** Has the driver complained to the eMSP about this session? If so, the eMSP should have context. * **eMSP-side telemetry.** Does the eMSP's app show anything useful — session start/stop events, driver location, reported issues? * **CPO-side telemetry.** The CPO's charge point management system should have charger status logs for the session window. **Decision:** If the session is implausible and neither side has context supporting it, reject. If it's plausible but extreme, accept. If you and your partner disagree, dispute and resolve directly. ### Charging speed The energy and duration on a CDR imply an average charging speed. A gap between that and the charger's rated power means one of the underlying values is off — wrong energy reported, wrong duration, or stale charger metadata. **Within 5%** (configurable tolerance): accept. Real-world charging tapers, throttles, and curtails — minor variation is normal. **Outside 5%:** dispute. Common causes are charger metadata that doesn't match reality, or a misreported energy or duration field. Ask the partner to verify against session telemetry. ### Timestamp issues **Negative or impossible timestamps** (start after end, future timestamps): reject. These CDRs can't be reconstructed and shouldn't enter billing. **Late-arriving CDRs.** Check your contract for the maximum allowed session age. Contracts typically specify a window — e.g., CDRs must be delivered within 14 days of session end — beyond which the eMSP isn't obligated to accept. If the CDR is outside the contractual window, reject with a reference to the contract clause. If it's inside, accept. ### Tariff cost consistency A gap between reported cost and ENAPI's calculated cost means one side's pricing logic is off. **Within 2%** (configurable tolerance): usually rounding or minor tariff interpretation differences. Accept. **Outside 2%:** something is materially wrong — wrong tariff applied, pricing bug, or a contract dispute in disguise. Dispute and resolve with your partner. Share ENAPI's calculated cost breakdown (available on the CDR detail page) so you're both looking at the same numbers. ### Short or low-cost sessions A CDR below your minimum energy or cost threshold isn't automatically wrong — it's automatically worth checking. Your contract likely defines a minimum billable session. Some contracts say "sessions under X kWh are not charged." Others bill everything. Check the contract. If the CDR is below the contractual minimum, reject. If there's no minimum defined, accept even small sessions — they're real. ### Missing CDRs This flag fires on sessions without a corresponding CDR, not on CDRs themselves. * **For CPOs:** investigate internally. Why didn't the session produce a CDR? CPMS bug, delivery failure, session never finalized? * **For eMSPs:** raise with the CPO. If the session existed and the driver was charged at the charger, a CDR is owed. ### Tune your rules over time The patterns you see in your CDR Inbox are the signal for tuning your rule configuration. Use what you learn from handling flags to adjust your setup in [Setting Up CDR Clearing](/cdr-clearing/setting-up-cdr-clearing.md). * **Rules firing too often on clean CDRs** — loosen the bounds. * **Real issues slipping through** — tighten the bounds, or enable additional rules in [Setting Up CDR Clearing](/cdr-clearing/setting-up-cdr-clearing.md). * **Recurring partner-specific patterns** — create a partner-specific rule set instead of bending the baseline. For example, a partner running ultra-fast chargers may need a higher energy upper bound than the default. --- # 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/cdr-clearing/how-to-handle-flagged-cdrs.md?ask=&goal= ``` `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.