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.

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

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

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

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.

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.

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.

Users must be able to set the logic/decision matrix used to determine when a countryMandate is used for any given record (invoice, credit note or other such as an aggregated report, consolidated invoice, payment record, etc) for a specific company/entity. The user should also be able to set a logic/decision matrix to determine which of the available dataFormats should be used for that mandate.

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) available for that mandate.

A user must be able to use fields from any of the record types they have defined in the mandate determination execution settings to set up the logic decision matrices within mandate configuration.

Pre-populated, suggested logic sets that are editable are acceptable, and encouraged.

The same mandate configuration MAY be used to manage how your connector handles inbound documents.

Users can - within their mandate configuration - define which field on the customer (buyer) record will contain the preferred output data format. If your application also has control over the customer record schema, the option list of possible output data formats will be made available from which users can select.

This is required if you are implementing the suggested Document Lifecycle > Dynamic output data format feature.

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

The connector will implement a dedicated Activation Monitoring section within the configuration interface. This section will query the Avalara ELR Activation API to retrieve and display the current status of each selected mandate per company.

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

The connector will perform a pre-submission validation check against the current activation status of the selected mandate and company. This check occurs just before a document (e.g., invoice, credit note) is submitted via the ELR API.

If the activation status is not Complete, the connector will:

• Prevent submission

• Display a clear, user-friendly message indicating the reason (e.g., "Cannot submit invoice – activation for Germany mandate is still in progress").

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.

Users can select event(s) related to any record type(s) they have implemented (such as invoice, credit note, payment record, aggregated report, consolidated invoice) that will trigger the mandate determination process for the record related to the event.

The user must be able to use the settings and related documentation to achieve full automation, in addition to manual triggering, regardless of the combination of source system record type, mandate and data format.

This MUST NOT be limited only to invoices and credit notes.

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.

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 (next) requirement.

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/conditional/optional input fields).

Pre-populated default/suggested values that are editable are acceptable.

For clarity, a "user" in this context, is anyone that the (your application and Avalara ELR) tenant holder engages and appropriately authorizes (provide access) to the relevant systems to implement customization requirements.

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.

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).

Detail your plans for log management, including the duration for which data will be retained in your system.

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).

Users can for a given document dynamically request a specific output data format from the list of supported output data formats applicable to the determined document mandate.

Users need to be able to understand the processing status of the submitted document, and any relevant error messages, such that they are available to any application connecting to the business systems APIs.

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.

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.

Users must be able to see an updated business status of a document, that has been responded to by the buyer (or updated by the seller).

Users can click a button to import the inbound document into the ERP/Purchasing System without manually entering document data. This implies that a user must also be able to select (within mandate configuration) and modify (customisable mandate mappings) an "inbound" mapping for this purpose.

Required if your application supports AP (Purchase) documents.

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.

Integrations must include the connector ID as a signature to all requests made to the Avalara ELR API. This value is provided to you by Avalara at the start of the project.

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.

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.

Users should have an easy and trouble-free installation experience described in the user guide.

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