Why your e-reporting flows will be rejected even if your XML is valid

The PPF (Public Invoicing Portal) applies several layers of validation before accepting a flow: technical, applicative, semantic and functional checks. A flow can be rejected with a perfectly well-formed XML. The most frequent rejection codes: REJ_SEMAN for business logic inconsistency, REJ_UNI for duplicate data, REJ_COH for data coherence failure, REJ_PER for incorrect period assignment. These rejections almost always share the same root cause: a flawed product architecture upstream.

Confusion between transaction and payment

If your software does not explicitly distinguish the act of sale from the payment receipt, data will be incorrectly assigned to its fiscal period.

Premature aggregation

Consolidating data before preserving the unit-level detail makes precise correction impossible afterwards.

No versioning

When an error occurs on an already-transmitted period, correction requires a corrective flow (flux RE) that cancels and replaces all data for that period. Without transmission traceability, this mechanism cannot be implemented properly.

Missing regulatory qualification

Your software must know whether an operation is B2C or international B2B, what the declarant's VAT regime is, and what role they play in the transaction. Without these attributes natively structured in the data model, the flows produced will be systematically fragile.