E-Invoicing and Live Reporting badge requirements

Administration & Configuration

NameTypeDescriptionComments
Connection > E-Invoicing configurations window
Required

Users must be able to select which environment they want to connect to and authenticate to the Avalara ELR API service using one of the available authentication methods.

Connection > Test connection
Required

Users must be able to test that their Authentication credentials have worked successfully and they are connected to the ELR API service.

Connection > Enable integration
Required

Users must be able to enable/disable the connection with the ELR API.

Company Management > Get list of current companies
Required

Users can see a list of all companies that are already present in the Avalara tenant.

It is quite likely that your integration isn't the only integration that is/will be used by the Avalara tenant, so users and your business system must be aware of which companies already exist.

Company Management > Map business system companies to Avalara companies
Required

Users should be able to select a company record from the business system to map to an existing Avalara company record. This mapping should be stored or accessible by your integration. The business system company reference should be stored with the Avalara company reference too.

Company Management > Add a company from business system
Suggested

Users should be able to select a company record from the business system, and add that company to the Avalara tenant using the details from the business system.

Your implementation should check/provide user warnings that this company hasn't already been added, either by your integration or another.

Mandate configuration
Conditional

Users must be able to set the logic/decision matrix used to determine when a countryMandate is used for a given document (or other relevant ERP object record) for a specific company/entity. A user must also be able to select a default or customized mapping to be used for the selected mandate for all of the document types (dataFormats) that must be supported under that countryMandate. Pre-populated, suggested values that are editable are acceptable, and encouraged.

This functionality is required when your application can be used to produce sales (outbound documents/credit note) documents. The same mandate configuration MAY be used to manage how your connector handles inbound documents.

Expose activation process status
Required

Users can see a status for each activation process that has been started.

This could be within your mandate configuration section.

Block mandate usage through activation status
Required

Your integration blocks the sending of a document through a countryMandate by a company for which the activation process status is not 'Complete'.

You could also achieve this feature by checking the activation status before allowing a user to 'enable' a mandate configuration.

Mandate determination execution
Conditional

Users can configure the frequency, and/or event/action upon which the mandate configuration logic is processed.

This functionality is required when your application can be used to produce sales (outbound invoices/credit note) documents.

View mandate mappings
Required

Users can view the integrations default/suggested mappings for each documentType possible for each countryMandate that your integration has been designed and tested to support.

Retrieve relevant input fields by countryMandate
Required

Users can select a countryMandate to retrieve and view a list of data input fields needed to support the selected countryMandate. The endpoint supporting this requirement is best used for the purposes of preparing a default mapping file/suggestion per documentType per countryMandate for users to subsequently confirm and edit. The endpoint is NOT intended to be used to produce an input data document at runtime.

This requirement goes hand in hand with the Customisable Mandate Mapping requirement.

Customisable mandate mappings
Required

Users can clone any existing mapping (including value transformations), edit and save to cover any customizations they have done as part of their ERP/application implementation (source fields), or any specific use cases that would not be covered by your provided default mappings (adding required input fields).

For clarity, a 'user' in this context, is anyone that the tenant holder engages and appropriately authorizes to the relevant systems to implement customization requirements.

User Guide
Required

Users must be able to access a guide explaining how to initially configure, use on a daily basis, and maintain the integration. This includes explicit links to other existing documentation on native features that your integration utilises, and the contextual explanation of how and why such native features should be used in combination with this integration.

You will need to provide Avalara with the public link to the user guide or an attachment containing same information as a non-public link.

API logs
Required

Users must be able to access logs containing the raw request and response (headers and body) for all API calls made by the integration to the ELR API to help facilitate troubleshooting. How long the logs are persisted is up to you (1 week / 1 month etc).

Document Lifecycle

NameTypeDescriptionComments
Submit the document
Required

Users must be able to submit a document with the input data set they have specified for a given E-Invoicing mandate/specification. In some cases, manual re-submission may be required. This needs to be accommodated through validation and the Mandate Determination Execution process.

This functionality is required even if your system is 'AP only'. This is because you must be able to support responding to received documents (through ApplicationResponse).

Get the status of the sent document
Required

Users need to be able to understand the status of the submitted or received document.

Store responseKey and responseValue pairs
Required

Users must be able to view any error messages and any responseKey and responseValue pairs. The responseKey and responseValue pairs must be stored on the business system document record in such a way that other apps can access that data programmatically.

This is to ensure users can use other common apps to prepare PDF templates and include responseValues on those PDFs. The data must also be available to the mapping process described under Customisable mandate mappings.

Download the document
Required

Users can view within your application all the formats available for a given document. The formats must be stored in such a way that other applications connected to your business system can retrieve them programmatically, so that they can be used in related business processes that occur outside of this integration.

To mitigate any potential concerns around storage costs, you may choose to provide additional configuration options within the Mandate Configuration to allow users to define on a mandate by mandate basis which formats to automatically download for them.

Receive an ApplicationResponse
Conditional

Users must be able to see an updated status of an outbound document, that has been responded to by the buyer.

This functionality is required if your application supports AR (Sales) documents.

Import inbound document to client application
Conditional

Users can choose to click a button to import the inbound document into the ERP/Purchasing System without manually entering document data. If the ERP application supports a posted/un-posted status (or equivalent) for a document type, the document should be imported with the status of unposted.

This functionality is required if your application supports AP (Purchase) documents.

Import inbound document automation
Suggested

Users can configure the frequency on which an automated process to import the inbound document is run. This may already be existing functionality. Pre-populated default/suggested values are acceptable.

Only relevant for applications that support AP (Purchase) documents.

Server Audit Clarity and Installation Requirements

NameTypeDescriptionComments
Pass Connector Identifier Information via the X-Avalara-Client header
Required

The integration must pass a 'connectorId' value in the 'X-Avalara-Client' header for ALL requests made to the Avalara API.

Value to be passed will be provided by Partner Launch Services for signed Technology Partners and AvalaraIncluded partners. This is not required for requests to the Authorization server.

Reasonable Messages on Server-Side Analysis
Required

There should be no errors except those that would result from normal (but invalid) user input. Such errors must be logged/displayed appropriately to the system.

Demonstrate and document installation of software
Required

A comprehensive, step-by-step installation documentation is required. This document should provide detailed instructions on how to install the ELR integration. It should cover all aspects of the installation process, from initial setup to final configuration.

The documentation should be easy to follow, and sufficient to enable Certified Implementation Partners (CIPs) to successfully install your ELR integration without any issues.