# BE priority and matching

Source: https://developer.avalara.com/products/excise/integration-guides/excise/uvx7262695522647/

Guide: AvaTax Excise

# BE priority and matching

Learn how ATE matches customers or suppliers in transactions with BE table records using configured priorities.

As mentioned previously, ATE transactions will attempt to match a customer or supplier in a transaction with a record in the BE table. This matching is determined by configured priorities. This section describes the matching and priority process in ATE.

**Matching** is simply a selection process, or the process by which an element of your master data is selected from the BE table for use in a current transaction.

For example, assume you send ATE information about a buyer with a `CustomId` of `12345` in transaction data. Using the buyer information, ATE will review the BE record for that buyer to see if there’s a BE with a `CustomId` of `12345`. At this point, behavior changes depending on whether ATE finds that match.

-   If there’s a match
    -   ATE will verify the buyer's legal name, address, and licenses.
    -   If any information about the buyer differs between what is in the BE and what is in the transaction (for example, the address), then ATE will follow your business practices to determine what to do (for example, update the BE, do nothing, and so on).
-   If there isn’t a match, then based on your business practices, ATE may attempt to create a new BE if there’s enough information.

Note Matching puts the burden on specific ID fields that are used to connect a record in transaction data with a record in the BE table. Once a match is made, the values in the table override any values provided in the transaction data.

**Priority** describes the way that identifying elements are used to make a match. The above example assumed matching based on the custom ID. In ATE, matching can be prioritized based on the custom ID (using `CustomIdPriority`), the legal name (using `LegalNamePriority`), and the BE ID code/type (using `IdCodeAndIdTypePriority`). The priority value for each decides the priority order when making a match. Example priority settings can be:

-   Custom ID priority `1`, legal name priority `0`, ID code/type priority `0`:
    -   Use just the `CustomId` to match an entry in the BE table. If a match isn't found, create a new record.
    -   Matching records solely on a BE's `CustomId` is generally the preference, but these priorities should follow your specific business practices.
-   Custom ID priority `1`, legal name priority `1`, ID code/type priority `1`:
    -   ATE will match a record based on the `CustomId`, `LegalName`, AND the ID code and type included in the [BusinessEntityIdCodes](https://developer.avalara.com/api-reference/excise/v1/models/Avalara.Excise.Common.Contracts.Services.BusinessEntityIdCode_5_37_0/) model.
    -   This priority matching most closely matches a system of record (SOR) matching rule.
-   Custom ID priority `1`, legal name priority `2`, ID code/type priority `2`:
    -   ATE will attempt to match on the `CustomId` first. If there isn't a match, then ATE will attempt to match on BOTH the `LegalName`, AND the ID code and type included in the [BusinessEntityIdCodes](https://developer.avalara.com/api-reference/excise/v1/models/Avalara.Excise.Common.Contracts.Services.BusinessEntityIdCode_5_37_0/) model.

Note It's possible for multiple business entities to have the same `CustomId`. This can occur when BE is obsolete (using `ObsoleteDate`), and then a new, unlocked entry is created by copying the obsolete BE. When performing a search based on a `CustomId`, ATE will search unlocked records first, then return any obsolete records.

**Parent topic:** [Business entities](/excise/bhy8503430047253/ "Learn about business entities and their role in ATE transactions.")