Why sales tax and VAT on recurring invoices is a build decision, not a setting
If you must invoice US states and EU countries from a self-hosted billing system, you need to decide early how tax gets calculated. In both Kill Bill and Lago, tax is produced by a tax engine plugin or external tax service that receives line items, customer location and tax identifiers from the billing system, and returns the tax amounts that appear on the invoice. The engine you choose, and who maintains the rules it applies, determines how much of the build sits in your catalog, your customer records and your integration code.
Neither Kill Bill nor Lago ships a complete tax rulebook for US sales tax or EU VAT. Rates, nexus thresholds, product taxability, exemption certificates and reverse charge treatment change over time and differ by jurisdiction, so the platform gives you hooks rather than answers. That means someone in your organization owns the tax configuration, the mapping from each plan and add-on to a tax code, and the process for reviewing changes. Confirm with your platform partner which plugins are maintained for your version, what each one covers, and whether the vendor supports the jurisdictions you bill in today.
The sections that follow cover the tax engine options, where tax rules belong in the billing catalog, reverse charge and e-invoicing obligations, and the ongoing work finance must keep in place. Before you read them, list the countries and states you invoice, the product types you sell, and who in finance signs off on tax filings. Those three inputs will tell you how much of the tax logic belongs in the billing platform and how much belongs in a service you buy.
Which tax and invoicing requirements the build must meet
This table maps the tax and invoicing requirements a self-hosted billing build must address to the source that governs them and what each one means for the implementation. Only the FTC Safeguards Rule and SEC Rule 17a-4(b) are supplied as binding sources, so rows that depend on sales tax or VAT rules are marked for confirmation with your tax advisor and the relevant authority.
| Requirement | Source | What it means for the build |
|---|---|---|
| Tax determination per customer location | No supplied fact sets a sales tax or VAT rule. Confirm with your tax advisor and the relevant tax authority. | Store the billing address and tax-relevant location data on each account, and pass it to the tax engine on every invoice. Confirm which location fields each jurisdiction requires. |
| Tax rules kept in the billing catalog | No supplied fact sets this. Confirm rate and rule handling with your tax advisor. | Decide which tax attributes live in the catalog (product tax codes, exemptions) and which sit in the tax engine. Document the split so finance can trace each invoice line. |
| Change control on tax rules and rates | FTC Safeguards Rule, 16 CFR 314.4, requires adopting change management procedures for information systems. | Route tax rule and catalog changes through a documented approval, test and release process with a named approver. Keep the change record with the invoice evidence. |
| Audit logging of tax calculations and overrides | FTC Safeguards Rule, 16 CFR 314.4, requires logging the activity of authorized users. Applies where the company is a covered financial institution. | Log who changed tax settings, exemptions and manual overrides, and when. Keep logs for the period your auditors and tax advisor set, and protect them from edits by the people they record. |
| Invoice retention period | SEC Rule 17a-4(b) requires broker-dealers to keep bills receivable or payable for not less than three years, the first two in an easily accessible place. Other sectors: confirm with counsel. | Set retention for issued invoices, credit notes and tax lines to the longest period that applies. Confirm the period with counsel, and plan storage that keeps recent records readily accessible. |
| Invoice and tax record immutability | SEC Rule 17a-4(b) covers originals of business communications. Confirm whether your invoice format must be preserved in original form. | Treat issued invoices as final records. Corrections should be made through credit notes and new invoices, not by editing the original record. |
| Testing of tax configuration | FTC Safeguards Rule, 16 CFR 314.4, requires periodic penetration testing and vulnerability assessments absent effective continuous monitoring. Tax accuracy testing is not set by a supplied fact. | Test tax outcomes for each jurisdiction and product type before each rule change. Keep test results with the change record. |
| Reverse charge and VAT invoice content | No supplied fact sets these rules. Confirm with your tax advisor and the relevant EU authority. | Confirm which VAT identifiers, exemption statements and buyer data each invoice must carry, and make sure the billing template and tax engine produce them. |
Which billing platforms fit a tax-sensitive subscription build
The right billing platform depends on where tax calculation lives, whether tax must also post to the general ledger, and who operates the integrations. The cards below compare the options by fit, tax integration path and what your team must confirm in its own environment before committing.
Kill Bill for catalog-driven tax
Kill Bill is an Apache-2.0 subscription billing and payments platform, and the latest release in our supplied sources is killbill-0.24.22, published September 29, 2026. Its plugin architecture is the main tax integration point: tax can be calculated by a plugin that calls an engine such as Avalara, or by rules your team writes and maintains. Confirm which tax plugins exist and are maintained for your jurisdictions, who owns plugin upgrades, and how tax codes are mapped to catalog products before you rely on them for invoices.
Lago for usage-driven invoicing
Lago is a self-hosted option for usage-based and recurring invoicing that many teams evaluate alongside Kill Bill. Tax handling depends on the integrations available in the version you deploy, so the tax path must be confirmed rather than assumed. Ask whether tax can be applied per line item, how tax codes attach to billable metrics, and whether tax is recalculated when a mid-period usage event or proration changes an invoice.
Billing SaaS as a comparison
A hosted billing product often ships with tax calculation and filing features already connected, which shifts maintenance to the vendor but moves fees that scale with revenue and customer data outside your infrastructure. Use it as the benchmark when comparing cost and control. Ask the vendor which tax jurisdictions are covered natively, which data leaves your environment for tax lookups, and how invoice history can be exported if you switch platforms later.
Odoo Community when tax posts to the ledger
Odoo Community is published under LGPL-3.0 and includes accounting modules that compute tax on invoices and post to the general ledger. It fits when tax reporting, invoicing and receivables must live in one system rather than being synchronized from a separate billing platform. Confirm that the localization for each country and tax regime you must support is available in the edition you plan to run, and whether any required features sit in Odoo Enterprise, which is licensed separately.
ERPNext for tax and ledger in one system
ERPNext, built on the Frappe framework, is licensed under GPL-3.0 and includes tax templates and general ledger posting in its core. It is an alternative to Odoo when your team prefers its accounting structure and deployment model. The check is the same as for any ERP: confirm the tax templates for your jurisdictions, how recurring subscription invoices are generated from your billing source, and who maintains the integration when either system is upgraded.
What belongs in the billing catalog and what belongs in the tax engine
The billing catalog should hold the tax attributes that describe what is sold and who buys it, while the tax engine should hold the rules that decide how much tax applies where. In practice, the catalog carries a product taxability code for each plan, add-on and usage metric, a tax category that tells the engine whether a charge is a subscription, a service, a digital product or a one-time fee, and exemption flags on the customer account. Rates, jurisdiction lookups, nexus thresholds and registration decisions stay in the engine, usually configured through the plugin that connects Kill Bill or Lago to a provider such as Avalara. Finance should confirm with the tax provider which codes it expects in each field before the first invoice is generated, because a mismatched code is the most common source of silent miscalculation.
Every change to a tax attribute needs an approval trail. A new add-on set to taxable, a plan moved to a different category or a price change that alters the tax base is as material to the ledger as a price change, so the change record should show who requested it, who approved it, the effective date and the old and new values. Teams running a self-hosted platform should check that catalog edits are restricted to named roles, that tax-relevant fields are logged, and that the same change is reflected in the tax provider's configuration. Where the billing system feeds revenue into financial statements, these records are the evidence auditors will ask to see.
Exemption certificates and VAT numbers belong on the customer account, not in the catalog, and finance owns their lifecycle. Each record should store the certificate or registration number, the issuing jurisdiction, the validity dates and a link to the stored document, with a named reviewer who checks expiry before renewal cycles. For EU business customers, the VAT number should be validated against the EU VIES service before reverse charge is applied, and the validation result and date should be retained. Ask the implementation partner how the account fields are structured, who can edit them, and whether a change to an exemption flag on a live subscription is applied to future invoices only or also to open ones.
How the tax build rolls out in phases
The sequence moves from knowing which tax obligations apply to proving that invoices calculate, validate and reconcile correctly before go-live. Each phase closes with a named artifact that finance and the implementation team sign off before the next phase starts.
Inventory jurisdictions and tax profiles
Finance and tax advisers list every country, US state and EU member state where the company sells, the registrations it holds, the product types each jurisdiction taxes differently, and which customers are business buyers with VAT numbers. The implementation team maps those answers to the billing accounts and customer fields that will carry them. The artifact is a tax profile inventory, signed by finance, that states which jurisdictions are in scope for the first release and which are deferred.
Map tax codes to the catalog
Each plan, add-on, usage metric and discount in the Kill Bill or Lago catalog is assigned a product tax category that the tax engine recognizes. Taxability rules for services, digital goods and bundled items are written down rather than inferred from product names. The artifact is a catalog tax mapping table, reviewed line by line against the price list, with unmapped products listed as blockers.
Configure the tax engine plugin in a test tenant
The implementation team installs and configures the tax engine plugin, such as an Avalara connector where the company holds a subscription, in a non-production tenant that mirrors the production catalog. Credentials, company codes, nexus settings and rounding rules are set in that test environment only. The check is a set of reference invoices whose calculated tax matches the expected results from the tax adviser's worksheet. The artifact is a configuration record and a test result log.
Test reverse charge and VAT number validation
Test accounts are created for domestic consumers, domestic businesses, cross-border EU businesses with valid VAT numbers, businesses with invalid numbers and non-EU buyers. The team confirms that reverse charge applies only where the rule requires it, that the invoice carries the required wording and buyer identifiers, and that a failed validation falls back to the correct treatment. The artifact is a signed test matrix covering each buyer type and each outcome, with any exceptions logged for tax review.
Review invoice templates and numbering
Invoice layouts are checked against the tax content each jurisdiction requires, including tax lines, rates, tax identifiers, currency and the sequential numbering rules finance applies. Credit notes, corrections and proration lines are included in the review because recurring billing produces them often. The artifact is an approved invoice template pack and a numbering specification, with sample invoices attached for each template.
Run a parallel comparison against existing invoices
For a defined period, the new tax configuration calculates tax on live or replayed subscriptions while the existing process, whether a billing SaaS or spreadsheet, continues to issue the real invoices. Finance compares totals, tax amounts, rates and buyer treatment invoice by invoice and investigates every difference before accepting it. The artifact is a reconciliation report that lists each variance, its cause and its disposition, signed by the controller.
Go live with a rate change runbook
The cutover follows a written plan that sets the order of catalog, tax configuration and template changes, the rollback steps and the named owners for each action. A runbook for future rate changes is handed to finance, covering who receives rate updates, how they are tested in the test tenant before release, and how historical invoices stay unchanged. The artifact is the go-live record and the rate change runbook, with the first production invoices checked against the parallel results.
Evidence finance and auditors ask for on tax calculation
This table maps each piece of tax evidence that finance and auditors typically request to the part of a self-hosted billing stack that produces it, along with what the team must keep current. Read it as a checklist for the implementation design: if a row has no owner in your architecture, the evidence will not exist when someone asks for it. Retention periods and the exact form of acceptable records should be confirmed with tax counsel and your external auditor before the design is final.
| Evidence | Produced by | What finance must maintain |
|---|---|---|
| Tax configuration history | Billing catalog and tax engine plugin settings, exported from the billing database and version controlled | Dated record of which tax settings applied to each product, customer region and period, including who approved each change |
| Rate table versions | Tax engine (for example, an Avalara plugin) or an internal rate table loaded into the billing system | Versioned copies of rates and effective dates, kept so historical invoices can be recomputed exactly as issued |
| Invoice tax detail lines | Invoice records in Kill Bill or Lago, with tax amounts, jurisdictions and rates stored per line | Confirmation that each issued invoice shows tax by line, jurisdiction and rate, and that the totals reconcile to the general ledger |
| Exemption certificate records | Customer account data and document storage linked to the billing account, or the tax engine's certificate store | Valid certificates on file for exempt customers, with expiry tracking and the reason each exemption was applied |
| Reverse charge and VAT number validation | Customer tax identifiers stored on the billing account, with validation results from the tax engine or a VIES check you run | Records showing the buyer's VAT number, when it was checked, and the invoice wording used for reverse charge treatment |
| Change tickets for catalog tax changes | Your change management system, linked to catalog or plugin configuration changes in the billing platform | A ticket for each tax rule change with requester, approver, test evidence and deployment date |
| Retention of issued invoices | The billing platform's database plus an archive you control, with invoice PDFs and XML stored outside the application | Retention periods set with counsel for each jurisdiction, tested restores, and a documented process for legal holds |
How reverse charge and e-invoicing change the invoice data model
A reverse charge invoice is only correct if the data model can prove the buyer is a VAT-registered business in another EU member state. In a self-hosted Kill Bill or Lago build, that proof does not come from the tax engine alone. The account record needs fields for the buyer's VAT identifier, the country it was issued in, the date it was last validated and the result of that check. The tax calculation layer, whether a plugin such as Avalara or rules kept in the billing catalog, then reads those fields to decide whether to apply zero-rated treatment and which invoice wording to print. Finance should confirm with its tax adviser which invoice statements each supply type requires, because the wording and the evidence the buyer and the tax authority expect are set by national law.
Validation is a process as well as a field. Decide who can enter or change a buyer VAT number, whether the number is checked against the EU VIES service at onboarding and at renewal, and what happens when the check fails or the service is unavailable. Keep the validation result and timestamp on the account, and keep a copy of the check output with the invoice so a later audit can reconstruct why no VAT was charged. Changes to a customer's VAT status mid-term should create an auditable event, not an overwritten value, so that past invoices remain explainable.
E-invoicing adds a second layer. Some jurisdictions require invoices to be issued or reported in a structured format, and those requirements differ by country, by buyer type and by timing. A PDF generated from the billing system may not satisfy them. Treat the invoice as data with a defined schema, and make sure every field a mandate needs (seller and buyer identifiers, line-level tax category, document type and numbering) exists in the model before go-live. The open source e-invoicing and Peppol content group covers the national mandates in detail. Your team must confirm which mandates apply to each invoice flow, including cross-border B2B and B2C sales, before finalizing the schema.
What buyers ask before they hire help with billing tax
How much effort does a sales tax and VAT build take?
The effort depends mainly on how many tax jurisdictions and product types the catalog touches, not on the billing platform alone. A catalog with one country, one tax rate per product and a single payment gateway is a much smaller job than one that sells into multiple US states with economic nexus thresholds and several EU member states with different VAT treatment for digital services. Each additional jurisdiction adds rules to define, test and document. Ask any partner to break the estimate into catalog mapping, rule configuration, tax engine integration, invoice template changes and testing, and to state which of those steps they assume your team will perform.
How long does each phase of a tax implementation take?
Duration follows scope, so no fixed figure applies across clients. The phases usually run in order: requirements and jurisdiction mapping, catalog and product tax code design, integration with the chosen tax engine or plugin, end-to-end testing against sample invoices, and a parallel run before go-live. Gateway behavior, the number of open questions about tax status of customers, and how many invoice formats must change all stretch the timeline. Request a written schedule with each phase tied to a deliverable and to the inputs you must provide, and confirm it against your own release calendar before accepting it.
What does finance and engineering need to provide during a tax build?
Finance owns the tax positions: which jurisdictions you must register in, which products are taxable where, how exemptions are evidenced, and how reverse charge applies to business customers with valid VAT numbers. Engineering owns the integration points: the billing catalog, the invoice pipeline, the gateway webhooks, the tax engine credentials and the ledger export. Both teams should agree in advance on who approves a rule change and where the approval is recorded. Without a named owner on each side, tax rules tend to drift from the catalog and the drift is hard to detect until a filing is due.
Can an internal team set up tax on Kill Bill or Lago without a partner?
A capable internal team can do it if it has engineers who know the billing platform's plugin model, a finance owner who understands the tax rules, and time to test every rule against real invoices. The risk sits in the edges: exemption certificates, rate changes, invoice numbering for tax documents and refunds that reverse tax correctly. Ask whether your team has tested a full cycle of invoice, credit note and refund under each tax scenario you sell into. If the answer is no, a partner can supply a test plan and a review, but the decision on tax positions stays with your tax adviser and finance team.
Is a paid tax engine subscription required, and who pays for it?
A tax engine subscription is not required by the billing platform itself. Kill Bill and Lago can compute tax through plugins or through rules you define in the catalog, so the choice depends on how many jurisdictions and rate changes you must track. A commercial tax engine such as Avalara is paid for by your company under its own contract, typically on usage or account tiers set by the vendor, and it is separate from the implementation fee. Ask the partner to separate the one-time plugin work from the recurring tax service cost, and to confirm which plugin versions the vendor supports.
How do plugin upgrades affect tax calculations?
A plugin upgrade can change how tax is calculated, how invoice lines are labeled or how a tax code maps to a product, so it must be treated as a change to tax logic. Before upgrading the billing platform or a tax plugin, run the full set of test invoices from each jurisdiction and compare totals line by line. Keep the previous plugin version available for rollback, and record the test results as change evidence. Ask any partner how upgrades are scheduled, who signs off on tax output after each one, and whether a retainer covers regression testing.
What evidence should finance keep for audits of tax on recurring invoices?
Finance should keep the tax rules in force for each period, the catalog version that applied to each subscription, exemption and reverse charge evidence, and the test results from each rule change. Auditors and tax authorities will ask how a given invoice was calculated and who approved the rule behind it, so the trail has to link invoice, rule and approval. Confirm the retention period for these records with your tax adviser, since it depends on the jurisdictions where you are registered. Ask the partner which of these records the implementation produces automatically and which must be kept by hand.
Which questions to put to a tax-capable implementation partner
This sequence turns a vague request for tax support into a short set of answerable questions, so each bidder shows the same evidence on plugins, testing, change control, retention and post-go-live support. The output is a written scorecard you can compare across partners before a fixed-scope agreement is signed.
Ask about Kill Bill or Lago tax plugin experience
Ask the partner which billing platform version they have deployed with a tax plugin, whether that plugin is maintained by the platform project or written in-house, and how many live tax configurations they have run. Ask them to name the plugin and show a sample invoice with tax lines generated from it. You know this step is done when the partner provides a written answer that names the plugin, the platform version and the tax lines on a sample invoice, and you can check those claims against the project's own documentation.
Confirm the tax engine integration approach
Ask how the partner would connect an external engine such as Avalara to the billing platform, including which calls are made at invoice time, how product and customer tax codes are passed, and what happens when the engine is unreachable. Ask whether they have built or operated this link before and who maintains it after go-live. You know this step is done when the partner produces a short integration description covering the calls, the tax code mapping, the failure behavior and the named owner of the connector.
Test reverse charge and exemption scenarios
Ask the partner to describe their test cases for EU business customers with a validated VAT number, customers in other EU member states, non-EU customers and tax-exempt US customers with certificates on file. Ask how those cases are run in a sandbox before any production price change. You know this step is done when the partner shows a test matrix with expected outcomes for each customer type and records the results, including invoices that should show a reverse charge note and invoices that should carry tax.
Define catalog tax change control
Ask who may change tax codes, tax rates or the mapping between catalog products and tax categories, and how each change is requested, reviewed, tested and logged. Ask how the partner would handle a rate change that takes effect on a future date while existing subscriptions continue on their current terms. You know this step is done when the partner provides a written change procedure with named roles, an approval step, a test step and a log that finance can export.
Review invoice and tax record retention design
Ask how the partner would store each issued invoice with its tax lines, customer tax status, tax engine response and any credit notes, and for how long those records stay retrievable. Ask how the design supports the retention periods your tax and finance teams set, and how records are kept unchanged after issue. You know this step is done when the partner describes the storage location, the fields captured per invoice, the immutability approach and the retrieval test they will run, and your tax lead confirms the retention period in writing.
Agree the post-go-live support model
Ask how tax rate updates, plugin upgrades and engine API changes will be applied, who tests them, and how long the team takes to respond to a tax-related incident. Ask whether support is offered as a retainer, what is excluded, and how the partner would handle a filing deadline that falls during an upgrade. Any response times must be stated in the written agreement, not implied. You know this step is done when the support model, the scope exclusions and the escalation path appear in a document the partner signs as part of the fixed-scope proposal.
Integration points that carry tax data
Tax figures on a recurring invoice pass through at least five systems before they reach a return or a ledger. Each handoff is a place where a rate, an exemption or a VAT identifier can be dropped, duplicated or stored without evidence, so finance and engineering should review them as one chain.
Billing engine and catalog
Kill Bill or Lago generates the recurring invoice line items and decides which product, plan and charge each line belongs to. Tax behavior starts here: the tax code or category must be set on each catalog product, not guessed at invoice time. Check that changes to plans and tax codes are versioned, so a renewal from last year can be reproduced with the rules that applied then.
Tax engine connector
The connector sends the invoice lines, customer location and tax-relevant attributes to a tax calculation service such as Avalara, then writes the returned tax amounts back to the invoice. Confirm with the vendor and your plugin version which calculation modes, certificate handling and rounding behavior it supports. Log every request and response, because those records are the audit trail for a disputed rate.
Customer and VAT ID store
Billing addresses, tax exemption certificates and VAT registration numbers live in the customer record and drive reverse charge and zero-rated treatment. A stale or unvalidated VAT ID produces the wrong invoice wording and the wrong tax line. Decide who may edit these fields, how validation results are stored, and how changes are tied to the date they took effect.
Payment gateway settlement
The payment gateway captures the gross amount, including tax, and returns settlement and refund data that finance must match to invoices. Partial refunds and credit notes must reverse the tax portion in the same proportion as the original charge. Ask your gateway how it reports tax on refunds and whether that report matches what your billing system recorded.
General ledger export
Tax amounts, tax accounts and invoice totals move into the general ledger through an export or interface. Each tax rate should map to a specific liability account, so period-end returns can be reconciled to the ledger without manual adjustment. Confirm the export preserves tax lines separately instead of netting them into revenue.
Invoice archive and retention
Issued invoices, credit notes and the tax calculation records behind them need to be stored unaltered for the retention period your tax authorities and auditors require. Confirm the archive keeps the rendered PDF, the structured data and the tax engine response together. Self-hosted storage needs its own backups, access logs and encryption, which fall to your team to operate.
How DeployOpen works on this
DeployOpen plans, implements, integrates, documents and supports self-hosted billing platforms inside the client's own cloud accounts, data centers or air-gapped networks. For sales tax and VAT, we treat tax logic as a governed part of the catalog and the integration design, so finance can see and maintain every rule that touches a recurring invoice.
How we scope
- We document which jurisdictions, tax types and invoice flows the written scope covers before any build starts.
- We map each plan, add-on and usage charge to its tax treatment, including exemptions and reverse charge cases.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We integrate the chosen tax engine plugin with the billing platform and test invoices against agreed expected results.
- We keep tax rule references in the billing catalog so changes are versioned, reviewable and traceable.
- We configure invoice numbering, tax identifiers and reverse charge text to match the legal requirements confirmed by your advisers.
How we hand over
- We document the tax configuration, plugin settings, test cases and the change procedure finance and engineering will follow.
- We define the periodic review tasks for rate changes, registrations and exemption certificates, with named owners.
- We walk finance and operations through invoice reconciliation so the evidence trail is understood before go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We re-test tax calculations after platform upgrades or plugin version changes before they reach production.
- Your tax advisers and certified e-invoicing providers remain responsible for rate determination and filing decisions.
