A Comarch delivery status is not invoice acceptance

Ask which endpoint reported the status

Comarch's official record describes accounts-receivable distribution through channels that can include EDI, portals, and email, together with document delivery monitoring. A status from that workflow can be useful only when the record names the endpoint and event. Sent, delivered, downloaded, technically accepted, validated, cleared, received into an accounts-payable queue, approved for payment, and paid are different states owned by different parties.

Start with the question the status can answer. A transport acknowledgment may show that a message reached a gateway. A portal event may show that an identified user accessed a document. A tax-platform response may report schema validation or authority processing. None of those events automatically proves that the buyer accepted the invoice, that the authority accepted a tax position, or that the invoice entered the correct accounting and payment process.

Bind every event to one invoice version

Preserve supplier and customer legal entities, tax identifiers where lawfully used, invoice number, issue date, currency, document version, source-system identity, content hash, format, country profile, channel, endpoint, transmission time, message identifier, response code, response text, and observation source. If a conversion or validation changes the document, retain the relationship between the source record and the exchanged version rather than letting one status float across both.

Corrections need their own chronology. A rejected invoice may be corrected and resubmitted; a delivered invoice may later be disputed; a technically accepted document may fail a business rule; and a buyer may process a replacement while the original remains in an archive. Record supersession, cancellation, credit, resubmission, and duplicate handling explicitly so the latest interface label does not erase the history.

Keep recipient and authority decisions separate

Invoice exchange can involve a supplier, service provider, network, recipient, and tax authority, but their responses are not interchangeable. The evidence chain should identify who produced each response, which legal or technical model applied, what the code means under the current specification, and whether another acknowledgment is still expected. A recipient's business rejection does not necessarily reverse an authority event, and an authority response does not establish commercial acceptance or payment.

Carry the exchange record into accounts receivable, accounts payable, tax reporting, filing, payment, archive, and reconciliation only through named handoffs. Test missing acknowledgments, delayed responses, endpoint changes, duplicate submissions, invalid identifiers, format conversion, partial rejection, replacement invoices, and status reversals. The control owner should be able to reconstruct what happened without treating Comarch's interface as the controlling authority.

Read the Comarch record narrowly

The registered Comarch source establishes current official positioning for invoice validation, conversion, multi-channel exchange, delivery monitoring, ERP integration, and archiving. It does not establish legal applicability, configured jurisdiction coverage, recipient identity, authority acceptance, invoice validity, tax treatment, reporting, payment approval, settlement, archive sufficiency, or compliance for a particular transaction.

Indirect Tax Monitor reviewed the official record on August 25, 2026 and did not operate Comarch e-Invoicing. Buyers should demonstrate one invoice through source creation, conversion, validation, routing, acknowledgment, recipient response, authority response where applicable, correction, archive, accounting, payment, and reconciliation. The demonstration should include a response that changes after the first apparent delivery.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Indirect Tax Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.