feat(billing): add tax id fields to billing details and contract requests#284
Open
dashed wants to merge 3 commits into
Open
feat(billing): add tax id fields to billing details and contract requests#284dashed wants to merge 3 commits into
dashed wants to merge 3 commits into
Conversation
…ests Carry the customer's tax registration number across the platform billing service boundary so contract invoicing can compute sales tax with the correct treatment (e.g. EU reverse charge for registered businesses). - BillingDetails.tax_number (field 6): mirrors the stored billing-details tax number, returned by GetBillingDetails. - CreateContractRequest.customer_tax_id (field 7) and RolloverContractRequest.customer_tax_id (field 6): let the caller forward the resolved tax id into contract creation and rollover. All three are optional string fields with new field numbers, so the change is backwards compatible. REVENG-15
|
The latest Buf updates on your PR. Results from workflow ci / buf-checks (pull_request).
|
Add a doc-comment to BillingDetails.tax_number for parity, and note the reverse-charge use on the contract requests' customer_tax_id. Regenerated Rust bindings carry the comments.
brendanhsentry
approved these changes
Jun 3, 2026
| // The customer's tax registration number (e.g. VAT ID), used to determine | ||
| // tax treatment for this contract (for example, reverse charge for | ||
| // tax-registered businesses). Unset if none is on file. | ||
| optional string customer_tax_id = 6; |
Member
There was a problem hiding this comment.
Why do we need this for rollover contract? We pass the invoice line items through this request. So doesn't it make more sense to make use of the customer_tax_id when determining the line_items to pass to this request?
Member
Author
There was a problem hiding this comment.
@brendanhsentry im moving the tax calculation to upstream in the invoicer service rather than at the contract service. this changed the protos a bit. i'm preferring the protos field additions in #286 instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the customer's tax registration number to the platform billing protos so contract invoicing can compute sales tax with the correct treatment (for example, EU reverse charge for tax-registered businesses).
Context
This isn't a new concept — it exposes a value the billing system already stores per customer and already forwards to the tax provider:
BillingDetails, set and VAT-validated through the billing-details API.businessIdentificationNo(AvaTax), and a present tax id is what drives reverse-charge treatment for tax-registered businesses (e.g. in the EU/UK).These fields add the two wire hops that were missing:
BillingDetails.tax_numberexposes the stored value overGetBillingDetails.CreateContractRequest.customer_tax_id/RolloverContractRequest.customer_tax_idlet the caller forward it into contract creation and rollover, where tax is computed.The two names mirror their respective domains:
tax_numbermatches the persisted field, whilecustomer_tax_idmatches the tax-calculation input it feeds.Changes
BillingDetailsbilling_details/v1/billing_details.protooptional string tax_number = 6CreateContractRequestcontract/v1/endpoint_create_contract.protooptional string customer_tax_id = 7RolloverContractRequestcontract/v1/endpoint_rollover_contract.protooptional string customer_tax_id = 6GetBillingDetailsResponsealready embedsBillingDetails, so it returnstax_numberwith no further change.Backwards compatibility
All three are new
optionalfields with previously-unused field numbers — additive only, with no field reuse, rename, or type change — so the change is backwards-compatible (buf breakingpasses againstmain).Codegen
Rust bindings are regenerated and committed (
rust/src/…billing_details.v1.rs,…contract.v1.rs). Python output is gitignored and regenerated by consumers.REVENG-15