e-bon
e-bon.ro
Troubleshooting

Fix ANAF report rejections (P7B / MF / JE)

Diagnose and resolve an ANAF rejection on a fiscal report — common reasons, how to check status via the reports endpoint, and the fix path for each category.

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.

Expected indicator on the report record: 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.
The categories listed below cover the rejection patterns we have seen so far — invalid signature on the export ZIP, schema mismatch against the published XSD, or duplicate submission of the same MF/JE for a closed fiscal day. If you see a rejection that does not match any of these patterns, open a support case so we can document it.

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ă) or JE (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.

Background on report types and what the AMEF actually emits: Reports API. Background on the lifecycle event: Webhook events › 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.