E-invoice states: accepted is not the same as validated

Accepted is not validated

An e-invoice workflow can show an accepted import before the work that matters operationally is complete. The useful model is not one green success flag. It is a sequence of states that can be inspected separately: parsed, validated, routed and accepted.

The Pennylane import documentation says a successful response confirms that a file was accepted and parsed. It also documents that sending can happen before Schematron validation completes, and that an invalid invoice may be rejected later by the platform. That does not mean every accepted invoice will fail. It means the first response should not erase the later checkpoints.

Pennylane also distinguishes a technical or non-conformity rejection from a customer refusal. Those outcomes belong to different parts of the workflow and need different owners. If a team collapses them into one status, an incident review becomes guesswork.

For an integration rollout, keep these questions visible: what was parsed, what was validated, where was it routed, and what final outcome did the platform or recipient return? When failures repeat across a batch, inspect the source system and its mapping rather than treating each invoice as an isolated mystery.

This is an operational workflow model, not legal or tax advice. Review the InvoiceBatch FR scope when you need a bounded way to inspect the product context.