Avalara E-Invoicing and Live Reporting (ELR) helps you automate compliance with global e-invoicing and real-time reporting mandates. Use a single API to handle country-specific formats, validations, and submission requirements.

Core capabilities

Manage e-invoicing and live reporting across countries through a single API.

Centralized global compliance

Handle local invoice formats, digital signatures, clearance models, and real-time reporting requirements.

Support for country-specific formats and mandates

Connect to ERP and billing systems using prebuilt connectors or REST APIs.

Prebuilt ERP and billing integrations

Add new countries without rebuilding integrations using configuration and a centralized dashboard.

Single integration, multi-country coverage

Access API documentation, integration guides, and environment setup in the developer portal. E-invoicing services are provisioned through standard onboarding to configure the correct mandates and connectivity.

Getting started

Avalara ELR integrates with ERP, accounting, ecommerce, and billing systems to exchange invoice data across your transaction workflows. Use APIs or prebuilt connectors to send data to tax authority platforms and e-invoice networks such as PEPPOL or national government platforms.

How it integrates

What Avalara E-Invoicing solves

When to use Avalara E-Invoicing

Avalara E-Invoicing

API reference

Directives for caching mechanisms in requests and responses

Controls resources the user agent is allowed to load for a given page

Controls the amount of referrer information sent with requests

Defines the permitted cross-domain policies

X-Avalara-Client

The version of the API to use, e.g., "1.6".

avalara-version

Whether to include the total count of records in the result.

count

Whether to return only the count of records, without the list of records.

countOnly

The number of items to skip in the result.

$skip

The number of items to include in the result.

$top

Document types for which this field is applicable for

Returns an HTTP status code and message for a 'bad request'

The three-digit HTTP error code for the bad request

Represents detailed error information for an individual entry in a batch request. Includes the index of the failed item and associated validation errors.

The index of the request that caused the error in the batch.

Represents a single batch search operation

BadInput

Timestamp when the batch search was created

Email of the user who created the batch search

Response schema for listing batch search details.

Count of code lists for the given query parameters

Array of code lists matching query parameters

Returns a code list definition for a specific country

Code list of document type identifiers for France, based on UN/CEFACT document type codes, with national (local) extensions where applicable.

System-generated unique identifier of the code list definition. Typically a UUID used to reference this code list internally or via APIs.

Human-readable name of the code list, usually describing what the codes represent (for example, document types, tax categories, currencies).

Two-letter ISO 3166-1 alpha-2 country code indicating the jurisdiction this code list applies to.

Textual description of the code list, including what it is used for and whether it represents a global standard (e.g., UN/CEFACT, ISO, EN16931) or a jurisdiction-specific/local extension of that standard.

Identifier of the underlying standard or authoritative source for this code list. This may be a formal code list name (e.g., UNCL1001), a standard reference (e.g., EN16931), or an internal standard identifier.

Array of versioned definitions of this code list for the given jurisdiction. Each entry represents a version that is valid for a specific effective/sunset date range, optionally per locale.

Displays a summary of information about a code list

Represents a single code entry in a code list version

The actual code value used in documents or systems. This is typically what appears in the e-invoice payload, such as a numeric or alphanumeric code from the official code list.

Detailed explanation of what the code represents, localized according to the locale field of the version.

Human-readable label or name for the code, localized according to the locale field of the version.

Represents a versioned definition of a code list for a specific jurisdiction and date range

Date from which this version of the code list becomes legally or operationally effective in the jurisdiction. Typically corresponds to a go-live, mandate, or release date.

Date after which this version of the code list must no longer be used in the jurisdiction. Use a far-future date (e.g., 9999-12-31) when the sunset is not yet known.

Array of code entries defined in this version of the code list. Each entry contains the machine-readable code value and its human-readable description in the given locale.

List of free-text reasons explaining why this version of the code list exists (for example, initial introduction, regulatory update, addition/deprecation of codes). Useful for audit and change tracking.

Mandates for which this field is conditional

Array of scenarios which describe when a particular field is conditional for a country mandate

Indicates whether the trading partner consents to being listed in the directory. If not provided in the payload, its value will default to true.

Specification identifier: An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms.

An object representing the acceptable values for this field

Array of CountryMandate names for which this field is not used.

Array of CountryMandate names for which this field is optional.

Array of CountryMandate names for which this field is required.

Count of collections for the given date range

Array of documents matching query parameters

Returns the current document ID and status

Represents the document's business lifecycle state based on responses from external actors (Tax Authority, PDP, or ERP), such as acceptance, rejection, or validation.

Document status. See the `supportedDocumentStatuses` field in the GET /mandates response for full status definitions.

Returns an HTTP status code and message for an 'exception'

The three-digit HTTP status code for the exception

Returns the unique ID of a successful document submission

Unique ID for this document that can be used for status checking and file downloads. This is a UID created by the Avalara E-Invoicing platform.

Displays a summary of information about the document

Unique identifier that represents the company within the system.

The two-letter ISO-3166 country code for the country where the document is being submitted

The e-invoicing mandate for the specified country

The date and time when the document was created in the system, displayed in ISO 8601 format with timezone

The name of the customer in the transaction

Array of status events associated with this document. Events are included in each document in the response only when the query parameter $include=events is passed; otherwise the events array is not populated.

The document direction, where issued = `out` and received = `in`

The date and time when the document was last updated in the system, displayed in ISO 8601 format with timezone

The date and time when the document was processed, displayed in the format YYYY-MM-DDThh:mm:ss

The document recipient based on the interface

The name of the supplier in the transaction

Array of string values associated with the custom attribute.

Returns an optional message with a 'forbidden' response

A message that informs the user that they may not access a resource

The algorithm used to create the signature.

Unique identifier of this specific resource.

Optional array used to carry additional metadata or configuration values for the identifier.

Identifier name (e.g., Peppol Participant ID).

Returns an optional message with a 'InternalServerError' response

A message explaining the bad request error

The mandate supporting B2G eInvoicing in Australia. This function will create a Peppol BIS 3.0 file and sends the invoice to the related recipient via the Peppol network

**[LEGACY]** This field is retained for backward compatibility. It is recommended to use `mandateId` instead.
The `countryMandate` similar to the `mandateId` is comprised of the country code, mandate type, and the network or regulation type (for example, AU-B2G-PEPPOL). 

The type of e-invoicing flow for this mandate

Link to the documentation for this mandate's e-invoicing flow

List of available media types for downloading invoices for this mandate

Format and version used when inputting the data

The `mandateId` is comprised of the country code, mandate type, and the network or regulation type (for example, AU-B2G-PEPPOL). Keep in mind the following when specifying a `mandateId`.
- A country can have multiple mandate types (B2C, B2B, B2G).
- A entity/company can opt in for multiple mandates.
- A `mandateId` is the combination of country + mandate type + network/regulation.

Lists the supported output document formats for the country mandate. For countries where specifying an output document format is required (e.g., France), this array will contain the applicable formats. For other countries where output format selection is not necessary, the array will be empty.

Indicates whether this mandate supported by the ELR API

List of document statuses defined by the mandate.

Indicates whether this mandate supports inbound digital documents

An Array representing the acceptable values for this field

Represents the number of times an element can appear within the document

Determines if the field if Required/Conditional/Optional or not required.

No sinature configuration properties are required when the no signature is used.

No properties are required when the no signature is included.

Returns an HTTP error code and message for a 'not found' error

The three-digit HTTP error code for a not found error

Mandates for which this field is not used

Mandates for which this field is optional

Format and version used when outputting the data

The total count of records in the dataset.

Returns a pre-signed URL to download the report file.

A pre-signed URL to download the report file. This URL is time-limited.

Represents a single report with full details including metadata and associated transaction IDs.

The two-letter ISO-3166 country code for which this report was generated.

The e-invoicing mandate for the specified country.

The type of document covered by this report.

The unique ID of the job that generated this report.

The date and time when the report was generated.

An internal reference path for the report.

The current status of the report. Possible values include: PENDING, PROCESSING, COMPLETED, FAILED, SENT_TO_PPF, ERROR.

The name of the tax authority for this report.

The total invoice amount covered by this report.

The tenant identifier associated with this report.

The total tax amount covered by this report.

List of transaction IDs associated with this report.

Returns the requested list of reports matching the query parameters.

URL to retrieve the next page of results when more items match the query. Omitted or null when there is no next page.

Count of reports matching the filter for the given query. Present when the request includes $count=true.

Array of reports matching the query parameters.

The date and time when the status event occurred, displayed in the format YYYY-MM-DDThh:mm:ss

 The type of number or acknowledgement returned by the tax authority (if applicable). For example, it could be an identification key, acknowledgement code, or any other relevant identifier.

The corresponding value associated with the response key. This value is provided by the tax authority in response to the event.

The document to be submitted, as indicated by the metadata fields 'dataFormat' and 'dataFormatVersion'

Basic webhook configuration without signature

The URL of the webhook endpoint to which event messages will be delivered

Unique identifier for the new or updated entity.

Represents a document status defined by the mandate.

The name of the status (e.g., Approved, Fully Paid).

Optional array used to carry additional metadata or configuration values that may be required by specific document types. When creating or updating a trading partner, the keys provided in the 'extensions' attribute must be selected from a predefined list of supported extensions. Using any unsupported keys will result in a validation error.

Does avalara support exchanging this document type.

Does trading partner support receiving this document type.

Represents a request to validate company’s tax identifier.

The two-letter ISO-3166 country code of the tax identifier.

Optional field for adding additional details required by specific tax authorities. Refer to the GET /tax-identifiers/schema API endpoint for the full request structure for a given country.

Represents the response for a tax identifier validation request.

Represents a participant in the Avalara directory.

Optional array used to carry additional metadata or configuration values that may be required by specific networks. When creating or updating a trading partner, the keys provided in the 'extensions' attribute must be selected from a predefined list of supported extensions. Using any unsupported keys will result in a validation error.

Avalara unique ID of the participant in the directory.

A list of identifiers associated with the trading partner. Each identifier should consistently include the fields name, and value to maintain clarity and ensure consistent structure across entries. When creating or updating a trading partner, the attribute 'name' must be agreed upon with Avalara to ensure consistency. Failing to adhere to the agreed values will result in a validation error. Further, when creating or updating a trading partner, the value provided for the attribute 'displayName' will be ignored and instead retrieved from the standard set of display names maintained.

Name of the participant (typically, the name of the business entity).

The network where the participant is present. When creating or updating a trading partner, the value provided for the attribute 'network' will be ignored.

Registration date of the participant if available.

A list of document types supported by the trading partner for exchange. Each document type identifier value must match the standard list maintained by Avalara, which includes Peppol and other public network document type identifier schemes and values, as well as any approved partner-specific identifiers. The 'value' field must exactly match an entry from the provided document identifier list. Any attempt to submit unsupported document types will result in a validation error. Further, when creating or updating a trading partner, the value provided for the attributes 'name' and 'supportedByAvalara' will be ignored.

Represents a specific validation failure within a request.

The name of the field that failed validation.

A human-readable explanation of the error for the specific field.

CustomException

A detailed description of the error type.

A detailed description of the specific error ocurrance.

The standard value for the metadata object in POST /einvoicing/documents 

partner-einvoicing

The date and time when the inbound document was accepted by the Avalara E-Invoicing Platform

The unique ID for this document that was returned in the POST /einvoicing/documents response body. This is a UID created by the Avalara E-Invoicing platform.

The unique ID for this report as returned in a GET /reports response. This is a UID created by the Avalara E-Invoicing platform.

JWT Authorization header using the Bearer scheme.

An API that supports sending data for an E-Invoicing compliance use-case.

Avalara E-Invoicing API

Get a list of code lists on the Avalara E-Invoicing platform for the specified country. By default, the API returns only non-expired code lists (code lists where the sunset date has not passed). To retrieve expired code lists or filter by specific date ranges, use the <code>effectiveDate</code> and <code>sunsetDate</code> query parameters. A Code List is a controlled set of predefined, standardized values used to populate specific fields in electronic documents (such as e-invoices). Each code has a stable, machine-readable identifier and a human-readable description. Code Lists are typically based on global standards (e.g., UN/CEFACT, ISO, EN16931) and may include jurisdiction-specific extensions or restrictions.

Header that specifies the API version to use (for example "1.6").

Optional header for a client identifier string used for diagnostics (for example "Fingerprint").

Two-letter ISO 3166-1 alpha-2 country code indicating the jurisdiction for which code lists should be returned.

countryCode

Filter code lists by effective date. Returns code lists that are effective on or before this date. Format: YYYY-MM-DD (ISO 8601). If not specified, defaults to the current date. sunsetDate is required when effectiveDate is provided.

effectiveDate

Filter code lists by sunset date. Returns code lists that have not yet sunset on or before this date. Format: YYYY-MM-DD (ISO 8601). If not specified, only non-expired code lists are returned.

sunsetDate

When set to true, the response body also includes the count of items in the collection.

$count

When set to true, the response returns only the count of items in the collection.

$countOnly

Returns a list of code lists for a specific country

A Code List is a controlled set of predefined, standardized values used to populate specific fields in electronic documents (such as e-invoices). Each code has a stable, machine-readable identifier and a human-readable description. Code Lists are typically based on global standards (e.g., UN/CEFACT, ISO, EN16931) and may include jurisdiction-specific extensions or restrictions. Code Lists are versioned, and each version may have defined effective and sunset dates to ensure that the correct set of allowable values is applied according to regulatory or jurisdictional requirements. By default, the API returns only non-expired code list versions (versions where the sunset date has not passed). To retrieve expired versions or filter by specific date ranges, use the <code>effectiveDate</code> and <code>sunsetDate</code> query parameters.

codelistId

Filter code list versions by effective date. Returns versions that are effective on or before this date. Format: YYYY-MM-DD (ISO 8601). If not specified, defaults to the current date. sunsetDate is required when effectiveDate is provided.

Filter code list versions by sunset date. Returns versions that have not yet sunset on or before this date. Format: YYYY-MM-DD (ISO 8601). If not specified, only non-expired versions are returned.

Retrieves a code list by ID for a specific country

This endpoint returns a list of required, conditional, and optional fields for each country mandate. Use the mandates endpoint to retrieve all available country mandates. Use the $filter query parameter to retrieve fields for a specific mandate.

Filter by field name and value. This filter supports only eq and contains. For more information, refer to the Avalara filtering guide.

$filter

Returns the optionality of document fields for different country mandates