Most quoting models assume one quote belongs to one country. That assumption falls apart the moment you build a salesforce multi-entity quote for a multi-market AV distributor operating across APAC, because a single quote routinely carries two distinct countries at once. One is the legal entity that places the order. The other is the place where the equipment actually gets installed. They are often not the same country, and conflating them produces a quote that prices correctly for the wrong jurisdiction.
We hit this directly while designing a Revenue Cloud implementation for a distributor with subsidiaries spread across ten markets. The fix was not a workaround bolted onto the side. It was a deliberate decision to treat the two countries as separate, first class concepts on the quote, and to wire the pricing engine so that the right one drives tax and import cost.
The two countries, and why they are different
Every quote in this model carries two country fields. The Subsidiary Country is the country of the legal entity placing the order, the entity whose name appears on the contract and whose signature commits to the purchase. The Deployment Country is where the hardware is physically shipped, installed, and commissioned.
Picture a regional customer whose procurement is centralized. The contracting entity sits in Singapore, so the distributor's Singapore subsidiary signs the deal. The actual rooms being fitted out, however, are in Indonesia. The order is signed in one country and delivered in another. That is the normal case here, not the exception.
The reason this distinction matters is that two different things follow two different countries. The legal entity that signs determines which subsidiary owns the deal, which pricebook and selling currency apply, and which approval chain the quote runs through. The place of delivery determines the tax liability and the cost of getting goods across the border. If you collapse both into a single "country" field, you either tax the wrong jurisdiction or compute import cost against the wrong border, and in cross border deals those are not rounding errors.
Tax and import cost follow the Deployment Country
The hard rule in this design is that tax, CIF, and duty are driven by the Deployment Country, never the subsidiary. The logic is physical. Customs duty and the CIF (cost, insurance, freight) loading apply because goods cross into the country where they will be installed. Sales tax applies because the supply happens at the place of delivery. The entity that signs the order has no bearing on either.
Concretely, CIF and Duty are computed only for lines flagged as imported goods, and the percentages come from a rate table keyed on the Deployment Country. The cost build is sequential: CIF loads onto the item cost first, then duty applies on top of the item cost plus CIF combined. Tax sits at the quote level and uses a tax code resolved from the Deployment Country as well. Both layers read the same field, so they always agree on which jurisdiction they are pricing for.
This is the second and third layer of the four-layer pricing model that the engine runs on every reprice. The country split is what makes those layers resolve correctly, because they have an unambiguous answer to the question "which border, which tax authority."
Three currencies on the same quote
Country is not the only thing that comes in multiples. A single quote in this model juggles three currency contexts at once.
The procurement currency is what the distributor pays the vendor when it buys the goods. This is the original cost, synced nightly from the ERP (NetSuite), and it can be a regional purchasing currency or the local currency of the supplier. The selling currency is what appears on the quote sent to the customer, constrained to either a major settlement currency or the local currency of the signing subsidiary. The reference currency is a single common currency that every quote is also expressed in, purely so deals across ten markets can be compared on one yardstick by finance and leadership.
The pricing engine converts procurement cost into the selling currency using FX rates fed from the ERP. The point worth holding onto is that cost, sell, and comparison live in three separate currency planes on one record, and the engine has to keep all three coherent.
FX is locked for the quote validity window
A quote that re-prices itself every time the daily FX feed updates is useless, because the number the customer agreed to would move under them. So when a quote is issued, the FX rate is locked and held for the quote's validity window. Within that window the converted prices do not move, even though the underlying daily rates keep changing in the background.
This gives the customer a firm price for as long as the quote is live, and it gives the distributor a defined window of currency exposure rather than open ended risk. A finance buffer on top of the locked rate is a separate policy lever, but the core mechanic is simple: lock at issue, hold for the validity period, re-price only when a new version is generated.
Changing the Deployment Country re-prices everything
Because the Deployment Country drives both tax and CIF/Duty, changing it cannot be a passive field edit. When a rep switches the Deployment Country on a quote, every line has to re-resolve its CIF and duty percentages against the new country's rate table, and the quote level tax code has to swap to the new jurisdiction. If even one line keeps the old country's rates, the quote's total cost no longer reflects the real import cost, and nobody notices until margin comes in wrong.
So the automation re-applies the rates across all lines whenever the Deployment Country changes, and it also pre-fills CIF, duty, cost, and margin when a new product is added, before the line is ever saved. The rep does not have to remember to reprice. The invariant the system enforces is that every line always carries the rates for the quote's current Deployment Country, no matter how the quote was edited to get there.
A worked example
Take a single quote where the legal entity sits in Singapore and the deployment is in Indonesia.
Attribute
Drives
Value on this quote
Subsidiary Country
Signing entity, pricebook, selling currency, approval path
Singapore
Deployment Country
Tax code, CIF rate, duty rate
Indonesia
Procurement currency
Vendor cost as synced from the ERP
Vendor's currency
Selling currency
Price shown to the customer
Singapore dollars (SGD)
Reference currency
Cross market comparison
Common reference currency
FX rate
Cost to sell conversion
Locked at issue, held for the validity window
The Singapore subsidiary signs and bills in Singapore's currency, but the CIF, duty, and tax all come from Indonesia because that is where the goods land. If the customer later moves the install to a third country such as Vietnam, the rep changes one field and the whole cost stack re-resolves against the new border.
Takeaway
Cross border quoting in APAC is not a one country, one quote problem, and modeling it that way bakes in pricing errors that surface as margin leakage. Separating the Subsidiary Country from the Deployment Country, then driving tax and CIF/Duty from the deployment side while routing the entity, currency, and approvals from the subsidiary side, keeps the legal and the physical reality of a deal aligned on one record. Layer the three currency contexts and a locked FX window on top of that, and you get quotes that are both legally correct and commercially firm.
If you are building Revenue Cloud for entities that sign in one country and deliver in another, we have done this end to end. Tell us about your markets at /contact, or see how we approach Revenue Cloud delivery at /service.
Top comments (0)