Tax calculation and integrations
Solvimon calculates VAT and sales tax on every invoice, either with its own tax category rules or by delegating the calculation (and filing) to a connected tax engine: Avalara AvaTax, Anrok, or Sphere.
Why this matters
Charging the wrong VAT or sales tax rate is a compliance problem, not a cosmetic one. Whether you rely on Solvimon’s built-in tax categories or connect a dedicated tax engine depends on how many jurisdictions you operate in and how much of the rate lookup and filing you want to outsource.
How Solvimon and a tax provider divide the work
Once a tax calculation integration is connected, Solvimon is the system of record for the invoice; the provider is the source of truth for tax law, rates, and filing. Solvimon doesn’t determine what you owe on a connected billing entity: it sends invoice data to the provider for every calculation and reflects the result back on the invoice.
Solvimon is responsible for:
Your tax provider is responsible for:
You are responsible for:
If no tax calculation integration is connected for a billing entity, Solvimon calculates tax itself with its native rate tables (for example, standard and reduced EU VAT rates per country) against the tax category and both parties’ countries.
What Solvimon sends and receives
Every tax provider expects a different payload shape, but the data Solvimon sends follows the same general pattern:
- Customer identity and address – the customer’s
registered_address(organization) orresidential_address(individual), used to determine jurisdiction. - Line items – one entry per invoice line, with its amount and the tax category (
STANDARD,NO_TAX, orEXEMPT) configured on the product, product item, or product category. - Currency – the invoice’s billing currency, used for rate lookups.
- Tax ID and exemption context – the customer’s tax ID(s) and
tax_exemptstatus, so the provider can apply reverse charge or exemption logic. - Billing entity context – the
company_codelinking the billing entity to your account on the provider’s side.
What comes back is applied straight onto the invoice: a tax amount per line, an invoice-level total, and (where the provider returns it) rate and jurisdiction detail. Solvimon surfaces this as a tax category summary per invoice: base amount, tax amount, percentage, the applicable rates, and any notes (for example, a reverse-charge note). See the invoice header report for the exact fields.
Configuring customers for tax calculation
Address. A customer needs a registered_address (organization) or residential_address (individual) with a country code for Solvimon, or a connected provider, to determine the applicable jurisdiction. Set it via PATCH /v1/customers/{id} or from the customer details page in Desk.
Tax-exempt customers. Mark a customer tax_exempt (with an optional note explaining why) directly on the customer resource; see tax exemption for how this is configured. When a tax calculation integration is connected, the exemption status is sent along with the calculation so the provider can apply the correct treatment; if you use a provider-side exemption certificate, use the same customer identifier in both systems so it matches up.
Customer tax IDs. A customer’s tax ID(s) are sent to the provider at calculation time, so it can determine reverse-charge eligibility for VAT-registered customers. See validating a customer’s VAT number below for checking a tax ID before you save it.
Merchant tax identifiers
A billing entity carries its own tax_id/tax_ids, registration_number, and registered_address, and can hold additional tax_registrations for jurisdictions where you’re registered separately from your main entity address. These are what appear in the invoice’s “sold from” details and on the PDF, and are the seller context passed to a connected provider.
Tax on credit notes and voids
- Credit notes follow the normal invoice lifecycle and reach
Final, so tax on a credit note is calculated the same way as on the invoice it credits: natively, or via whichever provider is connected to that billing entity. - Voids are different: voiding is only possible on
OpenorDraftinvoices, neverFinalones. A voided invoice never reaches finalisation, so it never gets forwarded to a connected provider for filing.
See credit notes for how crediting works.
Implementation
Via API
Connect an AvaTax integration to a billing entity:
Once the integration is ACTIVE, invoices for that billing entity are calculated through AvaTax automatically; no per-invoice configuration is needed.
Validating a customer’s VAT number
Validate a tax ID before saving it on a customer, so invalid EU VAT numbers don’t slip through:
For EU tax IDs, Solvimon checks validity against VIES, the EU’s VAT Information Exchange System. valid is VALID, NOT_VALID, or UNKNOWN – UNKNOWN is returned when VIES is unreachable or the tax ID’s country doesn’t support automated lookup, so treat it as “couldn’t confirm” rather than “invalid”.
To check which tax ID types are accepted for a given country before submitting one, use GET /v1/tax-id-types:
Via Desk
Configure a tax calculation integration from Settings → Integrations → Add integration, selecting the tax provider and entering its credentials. Tax categories, customer exemptions, and US sales tax percentages are configured as described in the Tax overview.
Edge cases
- Connecting an external tax engine to a billing entity doesn’t remove the need to set tax categories: providers like AvaTax still expect a product tax code, so map your product categories to the provider’s codes (or use
custom_tax_codesfor line types with no direct product mapping). - Reverse-charge and exemption treatment is applied by the provider, based on the tax ID and exemption status Solvimon sends; Solvimon itself doesn’t decide reverse-charge eligibility once a provider is connected.
- If a tax ID fails VIES validation, the invoice still generates. Validation is a check you run before saving a tax ID; it doesn’t block invoicing on its own.
- Voided invoices never reach
Final, so they’re never forwarded to a connected provider for filing; credited invoices do reachFinalagain and are filed the same way as any other finalised invoice.