Prepare PA/eReporting flows and monitor statuses

Understand the lifecycle

The cockpit lists available actions; the history contains acknowledgements and status changes. A PDF, selected population or clicked button is not a platform response. Keep preparation, submission, technical acknowledgement, acceptance, rejection, correction and resubmission distinct. Correct client, company, VAT, invoice or payment source data rather than hiding a structured error in wording.

Build the qualification sheet before opening the cockpit

Create one line per object with source reference, seller, buyer, country, B2B/B2C status, totals, VAT treatment, issue date, payment basis and expected route. For the selected invoice, copy values from the issued invoice and selected customer record. Add expected action, prerequisite, history searched, row found, returned status and next authorised decision. The sheet prevents sending first and understanding later.

Qualification is a business decision supported by data. French B2B, B2C, international and cash-basis payment objects need not share a route. Country or VAT number alone is insufficient: inspect customer type and context. When a source value is missing, identify the field to complete before transmission.

Concrete exercise

1. Copy the selected invoice, the actual gross amount, the selected customer and the selected matter.
2. Read seller and buyer identifiers at source.
3. Write the expected route before opening the cockpit.
4. Search all three histories using one company, period and reference.
5. Record zero rows as the search result, not an accepted status.

Read statuses as a chronology

Read the stages in order: source data, eligibility, preparation, submission, acknowledgement, platform processing, acceptance or rejection, correction and payment. A cockpit “to do” line comes before submission. A local sent flag is not a platform acknowledgement, and a rejection does not erase the original invoice.

For a real return, reconcile identifier, company, amount and date before interpreting it. Read the detailed message, then locate the source: customer identity, seller, VAT, line, payment, routing or connection. Apply only the authorised correction, retain the earlier return and explain why one new attempt is permitted.

Empty-history diagnosis

• Confirm database, company and access rights.
• Expand dates while keeping the unique reference.
• Verify platform configuration.
• Confirm whether an authorised submission actually occurred.
• If none occurred, define a prepared future test.

Treat any payment rejection as a separate exception

A SEPA rejection remains connected to mandate, RUM, collection reference, due date, bank, expected payment and customer account. Use the actual rejection code as an event identifier, not as a universal accounting conclusion. Read the actual code and reason, then decide through the authorised process whether to represent, correct mandate data or request another method.

Do not mark the selected invoice paid because a debit was prepared. Expected collection, bank file, acceptance, rejection, payment entry and matching are distinct. If an entry exists despite rejection, reconcile customer movements before payment reporting. Preserve rejection date and link.

What to check for a SEPA rejection

• Customer, mandate and collection reference.
• Actual rejection code and date.
• Effect on the customer balance and matching.
• Whether to represent the debit, correct the mandate or request another payment method.

Prepare the future authorised end-to-end test

If a history is empty, first check the selected invoice, customer data, company, platform and period. Do not create or transmit anything during the training. When your normal process later supplies a genuine identifier and return, use them to complete the status and compare the amount.

For a final check, start again at the invoice, follow its route, locate any acknowledgement, interpret each transition and verify that no duplicate was created. A test without remote response validates only preparation; a remote response not reconciled to its source validates only transport.

Reconcile the populations before period close

Use one row per invoice or payment with its Tempolia reference, expected route, external identifier when present and latest actual status. Compare the three histories separately. An empty history contains no external event; it is never a list of successful events.

Apply the same discipline separately to invoice, eReporting and payment histories. Do not copy a status between them. Keep the selected customer, matter and actual gross amount as the starting point. Leave external status columns blank until an authorised submission returns an identifier and response. If a payment rejection is visible, place it in the payment chronology only and link it to the original mandate and debit. It does not populate the invoice-rejection column.

Choose the next action

If a history is empty, check company, period, platform and reference. If no row appears, simply note that no external status is available for the selected object. Do not describe a platform fault or a successful transmission without an actual return.

Repeat the filters and source checks without the direct links. Make sure that a cockpit action is not read as an acknowledgement and that a rejected SEPA debit is not read as a rejected invoice. Leave missing external statuses blank and do not resubmit before reading the genuine return.