# Document types

Source: https://developer.avalara.com/avatax-dm-combined-erp/sales-tax-badge/transactions/simple-transactions/document-types/

# Document types

AvaTax can handle multiple different types of transactions, including Sales, Purchases, Returns (often called a refund or a reverse transaction), and Inventory transfers. Each transaction type is available in two forms: an invoice form, which is permanent transaction that will be stored and eventually reported to the tax authority, and an order form that is a temporary estimate. When combined, you get the following transaction types:

**Advice:** AvaTax also supports additional document types, including Reverse Charge and Customs. These document types apply to EU transactions only.

Transaction Type

Lifetime

Example

`SalesInvoice`

Permanent

A finalized sale made to a customer

`SalesOrder`

Temporary

A quote for a potential sale

`PurchaseInvoice`

Permanent

A purchase made from a vendor

`PurchaseOrder`

Temporary

A quote for identifying estimated tax to pay to a vendor

`ReturnInvoice`

Permanent

A finalized refund given to a customer

`ReturnOrder`

Temporary

A quote for a refund to a customer

`InventoryTransferInvoice`

Permanent

A finalized shipment of inventory from one location to another

`InventoryTransferOrder`

Temporary

An estimate for shipping inventory from one location to another

AvaTax uses the `type` field to differentiate between these types of transactions. If you forget to include the type field in the [CreateTransaction API](https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateTransaction/), AvaTax will assume you want a temporary estimate and will set a value of `SalesOrder`, which will not be recorded in AvaTax.

Many connectors will only ever work with Sales transactions; but if you are developing a plugin for an accounting system, you should expect to handle all different types of transactions. Let's discuss how each of these types is different.

## Document type workflow

The image below shows a typical workflow for invoices and orders (quotes) for marketplaces and ecommerce solutions.

![](https://www.avalara.com/content/dam/assets/illustrations/diagrams/ecommerce_transaction_workflow.png)

## Orders vs Invoices

Our customers require both the ability to [estimate tax for a transaction](https://developer.avalara.com/blog/2016/11/04/estimating-tax-with-rest-v2/) and to record the actual tax for that transaction. Many customers use AvaTax as a way to predict taxes before taking action - for example, showing “Estimated Tax” on a web storefront. Other customers use AvaTax to calculate taxes only at the moment the transaction occurs - for example when recording a sale in their accounting system.

In AvaTax, an “Order” represents a temporary transaction that is not saved, whereas an “Invoice” represents a permanent transaction that will be maintained. Think about these documents like you are a salesperson:

-   You begin by speaking to a customer and obtaining information about what they would like to purchase. With this information, you construct a [CreateTransaction](https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateTransaction/) request.
-   First, you calculate that transaction in AvaTax using a `SalesOrder` transaction type. This becomes a quote (or lead, or opportunity) that you can share with the customer. The quote is as accurate as the information you have on hand, but you know that the customer will review the quote before making a decision to purchase, so we do not record it in our accounting ledger yet.
-   The customer then reviews the quote and may or may not request changes. It could be that the customer wants to purchase one more line item, or maybe they want the shipping address changed, or maybe they have an exemption certificate they want to provide to change their taxable use conditions. These changes can be recalculated by resubmitting the transaction to AvaTax, each time using the `SalesOrder` transaction type.
-   If the customer decides to cancel the order, or not to make a purchase, no action is required. You do not need to cancel a `SalesOrder` - because it has not been recorded as a permanent transaction yet.
-   When the customer does choose to make a purchase, you can then recalculate the transaction in AvaTax using the `SalesInvoice` transaction type. The `SalesInvoice` transaction type represents a transaction that has occurred, and can then be recorded, queried, reported on, and eventually filed in a tax return to a taxing authority.

Because every type of transaction must be able to follow this same pattern, AvaTax supports all transaction types as both Orders and Invoices. Quotes and sales orders tend not to reflect actual sales and can often be abandoned (without a void or return processed). For this, we recommend using a document type of `SalesOrder`. Invoices usually represent an actual sale, so you can use a document type of `SalesInvoice`. Because the creation of an invoice does not usually represent the finalization of that sale, keep the document in an uncommitted status.

When the invoice is posted and the sale is recognized, the document should be committed by setting `commit=true` for the transaction or when adjusting a transction. Committing will only work when an invoice document type is used.

Returns and credit memos work just like invoices, but they should be sent with negative amounts and some date considerations. If invoices or returns are voided, that cancellation needs to be communicated to AvaTax with a CancelTax call.

It’s worth noting that the Invoice transaction types provide a key compatibility between Avalara’s tax calculation API and the Avalara Managed Returns Service. The Managed Returns Service supports filing taxes calculated with AvaTax - but you can only file taxes that were recorded using invoice types! Anything you calculated using an order type is considered a temporary estimate and won’t be reported.

Because order transaction types are temporary documents, it’s also worth noting that your transaction will not be retrievable later. All order transactions will have ID numbers that are -1, indicating that they cannot be fetched back using the API. Invoice transactions have positive ID numbers and can be retrieved back.

Next, let’s describe the various types of transactions and see how they work.

## Sales transactions

A `SalesOrder` or `SalesInvoice` transaction represents a sale that your company made to a customer. This is by far the most common type of transaction that AvaTax handles. As usual, a `SalesOrder` is an estimate and a `SalesInvoice` is a record of a transaction that occurred.

Sales transactions are generally expected to be recorded as they occur. For example, if you calculate an estimate for a customer using a `SalesOrder` on the 11th of the month, then convert it to a `SalesInvoice` on the 20th of the month, it is customary to choose the transaction date as the 20th. The AvaTax API natively supports this date behavior - just provide the date field on the [CreateTransaction API](https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateTransaction/) and your transaction will be recorded on that date.

## Return transactions

When a customer changes their mind and asks for a refund, you can process that refund by specifying a `ReturnOrder` or `ReturnInvoice` transaction, or you can call the [RefundTransaction API](https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/RefundTransaction/). This transaction type refers to a reversal of the charges that occurred when you originally made the sale. As usual, the `ReturnOrder` can be used for estimating and the `ReturnInvoice` is a permanent record.

Unlike sales transactions, return transactions have two dates. The first date is the date when the return occurred, and the second date is the date when the original purchase was made. Two dates are needed because the tax rate may have changed since the customer made the original purchase! Here’s how to refund the customer the exact amount they paid originally:

-   The `date` field of your `ReturnInvoice` is the date when the refund is issued. If you are filing tax returns using Avalara's Managed Returns Service, this `date` controls when the refund will be reported to the tax authority.
-   To specify the date when the original sale occurred, you use a [TaxOverride](https://developer.avalara.com/api-reference/avatax/rest/v2/models/TaxOverrideModel/) object in the [CreateTransaction API](https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateTransaction/). Set the `type` of the tax override to `TaxDate`, and set the `taxDate` field to the date when the original purchase occurred. This will tell AvaTax to calculate the tax amount returned to the customer as of the tax override date.
-   If the customer's original purchase was recorded in AvaTax as a `SalesInvoice`, you can use the [RefundTransaction API](https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/RefundTransaction/) to automatically refund the exact amount they paid originally. This API takes care of all the hard work of setting up the tax overrides for you.

## Purchase transactions

A purchase transaction represents a purchase made by your company from a vendor. A `PurchaseOrder` represents a quote you request from a vendor, and a `PurchaseInvoice` represents a finalized purchase transaction.

In the United States, most vendors will automatically charge and remit transactional taxes on your behalf. However, some companies choose to use AvaTax to identify any discrepancies between the tax rate you were charged by a vendor and the correct tax rate for a product or service. This calculation can assist a company in recovering overpaid taxes, or in identifying any cases where their vendor relationships are not in full compliance with tax laws.

Use a `PurchaseOrder` to get an estimate of the tax that you should pay on a transaction, and use a `PurchaseInvoice` to record a transaction that occurred. When reporting a `PurchaseInvoice`, specify the tax amount that you were charged by the vendor and have Avalara calculate the actual tax discrepancy. This allows you to correctly report Consumer Use Tax via Avalara’s Managed Returns Service.

## Inventory Transfer transactions

Inventory transfers are another way of tracking transactions that have Consumer Use Tax implications. For companies with multiple warehouses and offices, there are tax implications involved in shifting inventory from one location to another.

As with the other document types, an `InventoryTransferOrder` represents an estimate, and an `InventoryTransferInvoice` represents a permanent transaction.

[Previous](/avatax-dm-combined-erp/sales-tax-badge/transactions/simple-transactions/document-dates)

[Next](/avatax-dm-combined-erp/sales-tax-badge/transactions/simple-transactions/addresses)