Does Avalara calculate use tax on vendor bills in Loopfour?
No, not currently. AvaTax's own API supports purchase-side document types — PurchaseInvoice and PurchaseOrder — but Loopfour's Avalara integration restricts documentType to SalesInvoice or SalesOrder only. That's a scoping choice in Loopfour's integration schema, not an AvaTax limitation, and it means use tax on vendor bills has to be handled outside this integration today.
By Zuny Fester, Head of Operations and MarketingPart of the finance integrations guide.
| Answer | No — Loopfour's Avalara integration only creates SalesInvoice/SalesOrder documents |
|---|---|
| Is this an AvaTax limitation? | No — AvaTax's CreateTransactionModel documentType enum includes PurchaseInvoice and PurchaseOrder |
| Where the restriction actually lives | Loopfour's avalaraDocumentTypeSchema, which scopes documentType to Sales-side values only |
| What this means in practice | Use tax accrual on vendor bills must be handled outside this integration for now |
| Where this cluster's Avalara pages sit | Under AR, not AP — the integration is structurally sales-side only |
Why this is worth stating plainly
It's a reasonable question to ask, because AvaTax itself is fully capable of it. Avalara's own CreateTransactionModel API documents a documentType field with a broad enum — SalesOrder, SalesInvoice, PurchaseOrder, PurchaseInvoice, ReturnOrder, ReturnInvoice, and several others — explicitly covering both the sales side and the purchase side of a business. Use tax on a vendor bill is exactly what the PurchaseInvoice document type exists for.
Where the actual restriction lives
Loopfour's Avalara integration schema constrains the documentType field a workflow can pass to SalesInvoice or SalesOrder only. That's not something AvaTax enforces — it's a scoping decision in how this specific integration was built, presumably reflecting that the first use cases were AR-side (calculating tax on outgoing customer invoices), not AP-side (calculating use tax on incoming vendor bills). The practical effect is the same either way: a workflow can't currently create a PurchaseInvoice-typed transaction through this integration, even though AvaTax's API would accept one.
What that means for AP teams today
Use tax accrual on vendor bills — self-assessing tax a vendor didn't charge, on a purchase where the buyer's jurisdiction requires it — has to be calculated and posted through some other path for now: directly in AvaTax's own interface, through the accounting system's native use-tax handling, or manually. This is a real, current gap in this specific integration, not a workaround for an AvaTax limitation, which is the distinction worth keeping straight when planning around it.
Next step
Map the finance workflow with the most exposure and prove the automation path.
Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.
Field mapping
AvaTax's documentType enum vs. what Loopfour's Avalara integration accepts
| documentType value | Supported by AvaTax's API | Accepted by Loopfour's integration |
|---|---|---|
| SalesInvoice | Yes | Yes |
| SalesOrder | Yes | Yes |
| PurchaseInvoice | Yes | No — not currently exposed |
| PurchaseOrder | Yes | No — not currently exposed |
Frequently Asked Questions
Sources
Related
Topic
AP & Invoice Processing
Accounts payable and invoice processing is the set of steps a vendor bill goes through between arriving at a company and turning into a payment: capturing what the vendor sent, checking it against wha…
Read moreTopic
Integrations
Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…
Read moreDiagnostic
Why is Avalara rejecting a sales invoice with a DocumentCodeConflict error?
A DocumentCodeConflict means the document code you sent already belongs to a committed transaction in AvaTax. The fix is not a fresh code — retrying with a new code every time is exactly what creates duplicate tax transactions on a real network retry. Keep the code stable, derived from the source invoice, and call the adjust or void endpoint if the original genuinely needs to change.
Read moreDiagnostic
Does sales tax calculated by Avalara count toward ASC 606 transaction price?
Not if you elect the practical expedient in ASC 606-10-32-2A, which lets an entity exclude sales, use, and similar taxes collected from a customer from the transaction price entirely. Avalara's own model already keeps tax separate — totalTax and totalAmount are distinct fields, and grandTotal is what's shown to the customer, not the revenue figure.
Read more