Prepare PA/eReporting flows and monitor statuses

Understand the lifecycle

The cockpit proposes actions; history proves 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 18100016, copy values from the issued invoice and AGAPE 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 evidence is missing, write “not demonstrated” and the source to complete.

Concrete exercise

1. Copy 18100016, EUR 300.00, AGAPE and 2026-12.
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

A chronology links source, eligibility, preparation, submission request, technical acknowledgement, platform processing, acceptance or rejection, correction and payment information. Each step needs time, actor, reference and evidence. A cockpit “to do” line is pre-submission. A local sent flag without remote acknowledgement cannot prove receipt. A rejection identifies a failed external stage; it does not erase the commercial source.

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 RJMD01 as a separate payment exception

A SEPA rejection remains connected to mandate, RUM, collection reference, due date, bank, expected payment and customer account. RJMD01 is the exercise identifier, not 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 18100016 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.

Evidence package

• Invoice and customer identifiers.
• Mandate and collection reference where applicable.
• Actual rejection row or explicit unavailability.
• Customer-account and matching consequence.
• Approved next action, owner and deadline.

Prepare the future authorised end-to-end test

Because current histories are empty, define rather than execute the missing test: a dedicated invoice with known classification, complete parties, controlled period and unique reference. Record expected cockpit population. After authorisation, capture request, acknowledgement and first remote status. Retain any rejection and demonstrate source correction plus one resubmission. If successful, verify history object and amounts.

Acceptance is not a green screen. Another reviewer must start at the invoice, explain the route, locate the acknowledgement, interpret transitions and prove absence of duplication. 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

Build a control table with one row per expected object and columns for Tempolia reference, route, source-ready date, submitted identifier, acknowledgement, latest status, owner and next action. Count objects prepared, genuinely submitted, acknowledged, accepted, rejected and still awaiting evidence. Reconcile each transition: the submitted count cannot exceed source-ready objects without an explained exception, and every rejected item needs an owner. An empty history supplies zero observed external events; it is not a population of successful events.

Apply the same discipline separately to invoice, eReporting and payment histories. Do not copy a status between them. For invoice 18100016, retain AGAPE, matter 2026-12 and EUR 300.00 as the observed source anchor. Leave external columns unproved until an authorised test supplies a genuine identifier and response. If RJMD01 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.

Write a decision record another operator can execute

For every gap, state the observed fact, evidence, operational impact, next control, owner and completion criterion. A useful entry reads: “Invoice history empty for the documented company and period; 18100016 has no observed external identifier; transmission is unproved; run the authorised prepared test and retain identifier, acknowledgement and history row.” Avoid statements such as “platform problem” or “all clear” when the evidence does not support them.

Have a second operator reproduce the filters, source checks and chronology without your direct links. They must explain why a cockpit action is not an acknowledgement, why empty histories stop the proof chain and why a rejected SEPA debit does not establish a rejected invoice. The exercise passes when that operator can name the exact artefact needed to close every open column and knows not to resubmit before reading an authentic return.