Fix ANAF report rejections (P7B / MF / JE)
ANAF rejections arrive through the report.generated lifecycle on the device's report record. The rejection text is set verbatim by ANAF; e-bon surfaces it on the report document. This recipe shows how to fetch and interpret it.
status: "rejected" with a non-empty error field carrying the ANAF message. The HTTP request that submitted the report typically returned 2xx — the rejection happens asynchronously, after ANAF processes the file. Subscribe to report.generated (see Webhook events › report.generated) instead of repeatedly polling the report endpoint.Identify the rejection category
- Signature invalid on the export ZIP (P7B) — the device's fiscal certificate has expired, was renewed but the new certificate has not been resealed onto the AMEF, or the device's system clock has drifted enough that the embedded signature timestamp is rejected.
- Schema mismatch (XML) — ANAF tightened the XSD for
MF(Memorie Fiscală) orJE(Jurnal Electronic) and the AMEF firmware has not been updated to the matching schema version. This is a firmware-on-device problem, not an e-bon problem. - Duplicate submission for a closed fiscal day — the same MF / JE for the same day was already submitted (typically by a previous run of the same export). ANAF deduplicates on its side.
- Missing prerequisite report — you submitted an MF before the corresponding JE was accepted, or vice versa, where ANAF enforces ordering.
Check the report status
Fetch the report status — the path depends on the report type:
# Memorie Fiscală (MF)
curl https://api.e-bon.ro/api/v1/devices/{deviceId}/reports/mf/{reportId} \
-H "Authorization: Bearer <jwt>"
# Jurnal Electronic (JE)
curl https://api.e-bon.ro/api/v1/devices/{deviceId}/reports/je/{reportId} \
-H "Authorization: Bearer <jwt>"
# P7B export ZIP
curl https://api.e-bon.ro/api/v1/devices/{deviceId}/reports/p7b/{reportId} \
-H "Authorization: Bearer <jwt>"
A rejected report carries status: "rejected" and an error field with the verbatim ANAF text. Cross-check by listing recent reports of that type on the device:
curl "https://api.e-bon.ro/api/v1/devices/{deviceId}/reports?type=mf&limit=20" \
-H "Authorization: Bearer <jwt>"
Apply the fix
Read the error field verbatim
Do not paraphrase or translate the ANAF message before searching for it — the strings are stable and findable on the ANAF documentation portal. Preserve the original Romanian text.
Match the message to a category
Use the categories above. The keywords in the ANAF message are distinctive: "semnătură", "schemă", "deja transmis", "ordine".
Apply the category fix
For signature invalid, contact the authorised technician for the AMEF — e-bon cannot reseal a fiscal certificate remotely. For schema mismatch, contact the printer vendor for a firmware update to the current ANAF XSD. For duplicate submission, no action is required — the original transmission already exists. For missing prerequisite, generate and send the prerequisite report first, then re-send.
Re-send only after fixing the root cause
Once the underlying issue is resolved, regenerate and re-send the report. The new transmission is a fresh report record with its own ID, not a re-attempt of the original.
report.generated.Get more help
Open a support case at support@e-bon.ro or e-bon.ro/contact with the report ID, the verbatim ANAF rejection text and the device ID. If you suspect this is a previously-undocumented rejection category, flag it explicitly so we can update this recipe.
Webhook delivery failures and auto-disable
How to interpret `lastError`, the 5-attempt backoff schedule, the 20-failure auto-disable, and how to re-enable a webhook safely.
HMAC signature mismatch
Why `X-EBon-Signature` verification fails on your endpoint — clock skew, wrong secret after rotation, and body re-serialization gotchas.