Esker shared e-invoicing needs AP–AR role separation

Define the direction before applying a shared workflow

Esker says its e-invoicing offer brings supplier invoice receipt and customer invoice delivery together on one platform. The page separately describes accounts payable receipt, validation, and processing and accounts receivable delivery by channel and format. That is a provider account of product scope, not proof that a customer's configured entities, countries, formats, or controls are supported. The useful buyer question is whether a shared interface preserves two different invoice directions instead of making them look like one generic document flow.

For each transaction, record the legal entity acting as issuer or recipient, its role in the particular invoice direction, the counterparty, invoice and source-transaction identifiers, issue and receipt dates, relevant tax date, currency, document version, jurisdictional route, and originating system. AP intake may begin from a supplier's issued record, whereas AR delivery begins from the company's own issuance process. A shared invoice identifier, workflow template, or status label must not make the company appear to be the issuer of an inbound supplier invoice or the recipient of its own outbound customer invoice.

Assign approval and exception rights by legal entity

A common platform can still require different decision rights. AP may need to validate supplier identity, match the invoice to a purchase or service record, resolve duplicates, and approve accounting treatment and payment. AR may need to approve source billing data, authorize issuance, select the applicable exchange route, correct a rejected transmission, and manage customer delivery. Tax owners may review a country-specific rule or exception in either direction without owning all operational steps. The buyer should write those roles down for each legal entity and direction before reviewing a provider's permission screens.

Test segregation with a user who has authority to resolve an AP exception for one entity but no right to issue AR invoices for another; a service account that transmits outbound documents but may not approve tax treatment; and a reviewer whose role expires or transfers. Preserve the actor, role, entity, action, time, version, and disposition in the audit record. An administrator can configure a workflow, but that configuration does not itself establish that the legal entity assigned the underlying decision authority.

Keep each direction's evidence chain intact

For inbound AP, follow one supplier-issued document from received payload and channel through technical validation, business review, posting, payment approval, and archive. For outbound AR, follow a separately selected customer invoice from source billing approval through format conversion, dispatch, network or authority response where applicable, customer delivery, correction, and archive. The records may share infrastructure, but a transmission acknowledgment, recipient receipt, tax-authority response, accounting posting, and payment are different states. None should silently stand in for another.

Introduce a difficult case in each direction: a duplicate supplier invoice with a changed attachment; an AP invoice rejected after intake; an outbound invoice rejected by a destination while the ERP shows posted; a customer credit note that reverses only one version; and a role change during an open exception. Ask the provider to export the source and transformed versions, route and mapping configuration, response, approval, exception, and corrected record. Reconcile those exports to the relevant ERP and counterparty or authority evidence. The test is about identity, state, and accountability, not a claim that Esker's product passes it.

Do not turn platform breadth into jurisdictional assurance

Esker states that its platform supports AP and AR invoicing, multiple formats, Peppol and other interoperability routes, ERP connectivity, and archiving. The reviewed page also advertises geographic reach and compliance benefits. Those are provider claims. It does not establish a buyer's purchased package, local legal applicability, network enrollment, country profile, configured permissions, authority acceptance, tax result, delivery completeness, archive sufficiency, or audit outcome. The particular law, official technical specification, transaction, entity, and effective date remain separate inputs to any tax conclusion.

Indirect Tax Monitor reviewed the official page on September 22, 2026. No attributable material change after the previous successful daily cutoff was established. A buyer's next step is a two-direction, two-entity acceptance scenario with tax, AP, AR, IT, and internal-control owners recording what the platform demonstrates and what remains unsupported. This analysis is not tax, legal, accounting, assurance, security, or implementation advice.

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.