Cloud marketplace vs regional marketplace: which sells SaaS in LatAm

The contract cleared legal, cleared the procurement committee, and stopped dead at accounts payable. The buyer in Sao Paulo had already approved a US$ 90 thousand a year proposal, and finance discovered a week later that the supplier has no local tax registration, cannot issue a domestic invoice, and never stated the tax classification of the service for the remittance. The deal did not die on price and it did not die on product. It died on route.

Deciding to sell SaaS in Latin America is a decision about how the money comes in, made before the first lead arrives. It is the decision that ISVs (Independent Software Vendors, software companies that sell their product to other companies) targeting the region make early, and it splits into two routes: the cloud marketplace, which lists the software inside the consumption of the cloud infrastructure provider, and the regional software marketplace, which distributes with local infrastructure, a local contract, and payment in the buyer's currency. For most international ISVs entering the region now, the regional route delivers first revenue sooner, with less paperwork, and with the buyer paying by PIX, boleto or installments on a card. The cloud marketplace wins in one specific case: the enterprise buyer whose entire procurement runs through the cloud provider's invoice, under a contract large enough to absorb the channel fee. The two routes do not compete on the same criteria, and that asymmetry is what this article scores all the way to the verdict.

What is the difference between a cloud marketplace and a regional marketplace for selling SaaS in Latin America?

A cloud marketplace lists the software inside the invoice and the procurement program of an infrastructure provider, and the transaction leans on the buyer's spending commitment. A regional software marketplace distributes with a local presence in Latin America and contracts in the buyer's currency. The decisive difference is who carries the contracting.

On the cloud route, the provider's program carries the contracting. The software appears on that provider's invoice, inside listing, pricing and payout rules the ISV accepts as a closed package. On the regional route, what carries it is an infrastructure built to contract under local conditions: it issues the country's tax invoice, receives payment in local currency, and answers for the billing operation, so the ISV contracts on its own terms.

The two channels serve different buyers, and that is the first division in the decision. The cloud route buyer is the company that has consolidated its IT budget into one cloud provider's consumption and prefers everything, third-party licenses included, to show up on that invoice. The regional route buyer is everybody else: the company that pays suppliers by boleto, demands a domestic tax invoice, and sometimes can only approve the purchase if it is paid in installments. Neither buyer is wrong, but each one demands a different commercial machine from the ISV. The full map of distribution paths available in the region, from the direct channel to the partner channel, is in the guide How to sell SaaS software in Latin America: the international ISV map, and this article decides which of the two routes goes first, criterion by criterion.

The practical consequence of the difference shows up in reach. The cloud route converts only buyers who already hold a spending commitment with that provider, which segments the market outside the ISV's control. The regional route covers the whole market, because it does not depend on which infrastructure the buyer picked years ago. For an ISV arriving in the region with no track record, that is the first criterion that carries weight. Reach decides early.

Who signs the contract, and what paperwork does each route demand?

On the cloud route, the ISV adapts its commercial process to the marketplace's role: it accepts the provider's contract model and program structure and goes through the listing cycle before the first sale. On the regional route via Nexforce Marketplace, the ISV brings its own standard contract and its own programs. Its commercial process does not change.

What the difference produces is a transfer of responsibility. On the cloud route, the ISV negotiates private offers inside the channel's rules and absorbs the paperwork the program format requires. On the regional route, the local infrastructure carries that paperwork, and the operation does without its own fiscal entity in the country.

The contract detail decides more than it appears to. An ISV that already has mature paper, with its own purchase orders, SLAs and renewal cadence, does not want to rewrite that paper to fit a program's format. On the regional route, Nexforce Marketplace works with the ISV's own contractual standard, which keeps intact the machine the vendor has already run in other markets. And the operation is cloud-agnostic: transacting with Nexforce requires no commitment to any infrastructure provider, which leaves the ISV free to sell to any buyer, on any stack. The ISV renegotiates nothing.

The model for who assumes the sale is a separate and important variable: who sits between the ISV and the buyer, and with what fiscal and contractual responsibility. The options run from the classic reseller to the merchant of record, and the guide Merchant of record for software in LatAm: how to choose details how to evaluate that arrangement before signing. What matters here is the effect on paperwork: the more layers assume the contracting, the fewer documents the ISV produces. Zero bureaucracy for the vendor is not a slogan, it is the count of signatures and tax registrations that stop being the vendor's.

How does the Latin American buyer pay, and what does their invoice carry?

On the cloud route, the license payment runs through the cloud provider's invoice, in hard currency, inside the buyer's spending commitment. On the regional route, the buyer pays in local currency, by PIX, boleto or card, and receives a domestic tax invoice. The payment method is an approval criterion for the purchase, not an operational detail.

Installments and the currency lock belong on the same line. On the regional route, the purchase can be split into up to 12 installments with the dollar rate locked on the purchase date, which fixes the exchange rate at the moment of the decision, and the domestic tax invoice supports the accounting and tax treatment of the expense that the buyer's finance team will book.

That second statement deserves the full math, because it is the buyer's side that closes or unblocks the ISV's deal. A buyer in Brazil that contracts a supplier with no local presence pays the remittance abroad loaded with taxes that the buyer itself withholds and pays over. On the remittance for a technical service, the IRRF of 15% applies, set out in art. 765 of Decree 9.580/2018, a withholding that reaches technical services and technical, administrative and similar assistance services. CIDE, a 10% contribution on remittances abroad for technical services, applies to SaaS and technical services: the classification of SaaS as a technical service comes from SC Cosit 191/2017; the CIDE calculation base, with the IRRF included, is confirmed by SC Cosit 99/2018; and the exemption under §1°-A of art. 2° of Law 10.168/2000 applies exclusively to pure software licenses without technology transfer, a tax category distinct from SaaS. Service imports add PIS at 1.65% and COFINS at 7.6%, from Law 10.865/2004, plus the municipal ISS of 2% to 5% and the IOF on the exchange transaction, at 3.5% on the remittance for a service abroad (Decree 6.306/2007, art. 15-B, item XXIV, as amended by Decree 12.499/2025; the rate was 0.38% before 2025). On top of that set, the buyer adds a layer that is not a tax and that the Nexforce deck model treats as its own structural cost line, the currency conversion spread, illustrated in the 5% to 10% range of the remittance. Tax reform changes that picture in transition: LC 214/2025 extinguishes PIS and COFINS in 2027, absorbed by CBS; EC 132/2023, in the ADCT (arts. 125 to 129), sets the phase-out of ISS between 2029 and 2032, with extinction in 2033 and replacement by IBS, while IRRF continues to exist. Anyone repricing a license for the 2027 cycle and beyond should revalidate every component of the math against the rule in force on the day.

The domestic tax invoice is the axis. That invoice is what supports the whole equation.

When the contracting runs through the regional route, the buyer receives a tax invoice in reais from a domestic operation. For a company under Lucro Real, that invoice allows it to recover a credit of 9.25% of PIS/COFINS on the expense, a credit that the direct international remittance rarely captures. That differential is a feature of the current regime and narrows from 2027: under the reform, the corporate buyer credits IBS and CBS on the import of intangibles and services (LC 214/2025, arts. 47 to 56 and art. 64), so direct import becomes creditable as well for companies under the regular regime, which compresses the advantage the domestic invoice offers today. For a company under Lucro Presumido, which does not take PIS/COFINS credit on inputs, the gain is different: the locked exchange rate, a tax invoice in reais, and operational simplicity in processing the expense. On the ISV's side, that means the same license at the same price is cheaper for the buyer to approve, which shortens the sales cycle without touching margin. The comparison of marketplaces from the buyer's side, with the buyer's own evaluation criteria, is in the guide How to compare software marketplaces before buying SaaS, and how the cloud route works from the buyer's point of view is in Buying software through the cloud marketplace: what it is; both pieces show what the buyer checks before signing, and each item checked is a barrier the ISV has to clear from the other side of the table.

Contracting flows vary by cloud provider, and the practical rule is to verify the specific provider's program before pricing the channel, because transaction models are not uniform across them.

What does each route cost in take rate and total cost?

The cloud route charges the ISV a per-transaction fee whose percentage varies by transaction model and by provider program, and can run from single digits to double digits depending on the product and the buyer's tie to the provider. The two routes charge in different currencies.

Verifying the specific program, with the fees the provider publishes, is mandatory before pricing the channel. The regional route via Nexforce Marketplace charges the ISV nothing, with no minimum deal size. One charges a fee. The other saves cost on both ends: the cost of adapting the listing, the paper and the processes to the channel sits with whoever operates the channel, and the attack on the currency, tax and processing layers of the international remittance brings the buyer's outlay down.

Total cost on the buyer's side is where the difference becomes a number. The illustrative simulation in the Nexforce Marketplace deck starts from a US$ 100 thousand a year international contracting by a buyer in Brazil and runs on assumptions of the deck model itself, not on the rates cited above, which serve to explain the mechanics and not to reproduce this result. In the direct model, the remittance charges and the currency layers push the outlay to US$ 153 thousand; contracting through the regional route, the outlay drops to US$ 138 thousand, a reduction of roughly 10% in the total the buyer disburses. The deck also presents an illustrative net cost, of US$ 125,580 for the buyer under Lucro Real, a value that is an assumption of the model itself and does not derive arithmetically from the 9.25% credit described here. For the ISV, that delta is not a financial detail of the buyer's: it is the difference between the proposal that blows past the approved budget and the one that fits inside it.

That same compressed cost is what makes the software alliance arrangement possible, closing deals that the ISV's own discount cannot close: Nexforce generates savings on the buyer's or prospect's other software expense and uses that margin to make the ISV's contract viable. The lever is the buyer's total software bill, not the isolated license. Added to zero cost for the vendor and lower cost for the end client at both ends of the channel, the result is a route that competes on price without the ISV cutting margin, which no discount war on the cloud route can imitate.

How long until first revenue, and who controls the relationship?

The cloud route has a queue in front of revenue: the ISV goes through the program's listing and review cycle and then operates under the marketplace's rules. On the regional route, Nexforce pays the ISV upfront and gives the buyer up to 12 installments. Time to revenue and control of the customer go to whoever carries the contracting.

The cloud route's queue charges interest in time. While the ISV adjusts its listing sheet, price and materials to the program, the marketplace controls entitlement, the account data and the cadence of the buyer relationship. On the regional route, the ISV brings the contract it already has and keeps the commercial relationship from day one.

Working capital deserves its own heading, because it is pure asymmetry. In an installment sale, the traditional seller finances the buyer: it delivers the license today and gets paid over 12 months, carrying the credit risk and the capital cost. On the regional route the vector flips: Nexforce pays the ISV at once and carries the buyer's installments. The ISV removes the receivable from its balance sheet, the buyer gains the payment terms its budget requires, and the operation closes on both sides without either party depending on the other's cash position. Nobody finances the other's cash.

Control of the relationship is the criterion that survives every renewal cycle. On the cloud route, the marketplace's program sits between the vendor and the customer, and renewal, upsell and usage data run through the channel's rules. On the regional route, with the ISV's own contract in force, the ISV is the one that knows the customer, bills the renewal and sells the next module. For a company building a position in the region rather than a one-off revenue line, that criterion weighs more than any fee.

What is the consolidated decision table between the two routes?

The table below consolidates the seven criteria of the article, with how each route behaves on each one, and every row maps to an earlier section where the criterion appears with the numbers. It reads across two columns.

The table works as a checklist.

Reading the table correctly requires the ISV to compare its own book of buyers against both columns before choosing, because a single criterion rarely decides on its own, while the combination of spending commitment consolidated in one provider, a high-value contract and procurement centralized in the cloud invoice appears only in the cases where the per-transaction fee pays for itself.

Reading the table for a specific case is in the next section, with the conditional verdict.

Which route should you choose, in each case?

The choice depends on three variables of the ISV: the profile of the target buyer, the size of the contract, and the urgency for revenue. The decision order below covers the cases that show up in the practice of software distribution in the region, and the verdict for each case is explicit.

1. Enterprise buyer whose procurement runs through a cloud provider's invoice, with a high-value contract: the cloud route is the choice, because the channel rides on the spending commitment the buyer already holds and the contract size absorbs the per-transaction fee. When that is the case, the ISV does not have to operate the channel alone: Nexforce also runs the cloud marketplace path for the vendor, the second solution in the portfolio, and the ISV chooses between running its own channel or delegating it.
2. Diverse mid-sized buyers, who purchase out of a department budget on a short cycle: the regional route via Nexforce Marketplace is the choice, because the case is decided entirely inside each department's budget. Approval is departmental. Fragmented purchasing arrives through a domestic tax invoice, in local currency and on the payment method the department already uses, and the regional route delivers that whole package from the first contract.
3. Urgency for revenue inside the quarter: the regional route is the choice, because it removes the listing and review cycle that delays the first sale on the cloud route and pays the ISV upfront from the first contract.
4. Buyer who only approves installments or boleto: the regional route is the choice, because it is the only one of the two offering up to 12 installments with the exchange rate locked on the purchase date, PIX and boleto with a domestic tax invoice.
5. Multi-cloud strategy, or a buyer not bound to a single provider: the regional route is the choice, because transacting with Nexforce carries no cloud requirement at all, and the ISV does not fund a channel that segments its own market.

In five of the cases, the regional route wins; in the first, the cloud route wins with execution support. An ISV that wants to see the operation up close finds the solution for selling in Latin America through Nexforce's local infrastructure at https://nexforce.ai/marketplace, with the contracting, credit and settlement mechanics described in this article working in practice.

Frequently asked questions

<!-- Bloco marcado para schema FAQPage -->

Does an international ISV need to open an entity in Brazil to sell SaaS in Latin America?

On the cloud route, the ISV needs the fiscal structure the marketplace program requires in order to receive, which in practice means an entity or a fiscal arrangement abroad with a maintenance cost. On the regional route via Nexforce Marketplace, no: the ISV brings its own contract, Nexforce carries the local contracting, and the vendor receives without opening an entity in the country and without taking on Brazilian tax obligations. The entity requirement is a criterion of the route, not of the market.

Who takes the currency risk when the buyer pays in local currency?

On the regional route, the exchange rate is locked on the purchase date: the buyer pays in reais at the price it approved, and the ISV receives the agreed amount in local currency, which removes the currency swing between proposal and settlement. The lock eliminates exchange-rate variability, not the conversion cost embedded in the operation. In the direct model, the exchange rate between proposal and payment is a floating cost on the buyer's side, and the buyer is the one who raises it in the renegotiation.

If the buyer pays in 12 installments, when does the ISV get paid?

Immediately. Nexforce pays the ISV at once on closing, and the up to 12 installments are terms given to the buyer, not a wait imposed on the vendor. The ISV carries no receivable, provisions no buyer credit risk, and does not finance the customer's cash with its own capital, which is the cost that traditional installment selling charges the seller.

Is the cloud marketplace fee the same across every listing model?

No, and the variation is material. Cloud programs charge according to the transaction model and the buyer's tie to the provider, and the percentage can run from single digits to double digits depending on the product and the buyer's tie. Contracting flows also vary by provider. Verifying the specific program, with the fees the provider publishes, is a mandatory step before pricing the channel, because the fee changes the entire margin of the deal.

Can a Brazilian ISV use the same path to sell outside the country?

It can, and that is the secondary application of the same solution: Nexforce Marketplace publishes the ISV's listing on the Nexforce marketplace, eliminating the need to open a fiscal entity abroad to sell globally or to handle the complexity and the fees of international channels. The Brazilian ISV receives in BRL in Brazil, with simplified billing and without carrying the bureaucracy and obligations of entities outside the country, paying only a fee to Nexforce.

References and Further Reading

• Law 10.168/2000, which institutes CIDE on remittances abroad, with §1°-A of art. 2° on the exemption restricted to pure software licenses without technology transfer. Planalto
• Law 10.865/2004, which institutes PIS and COFINS on the import of services from abroad. Planalto
• Decree 9.580/2018, Income Tax Regulation, art. 765, 15% withholding on technical services and technical, administrative and similar assistance services. Planalto
• SC Cosit 191/2017, Solução de Consulta Cosit 191/2017, of 23/03/2017, published by the Brazilian Federal Revenue, on the classification of SaaS as a technical service (searchable base at normas.receita.fazenda.gov.br).
• SC Cosit 99/2018, Solução de Consulta Cosit 99/2018, published in the DOU of 27/09/2018, section 1, page 28, on the CIDE calculation base with the IRRF included (searchable base at normas.receita.fazenda.gov.br).
• Complementary Law 214/2025, consumption tax reform, transition from PIS/COFINS to CBS (extinction in 2027) and IBS/CBS credits on the import of intangibles and services (arts. 47 to 56 and art. 64). Planalto
• Constitutional Amendment 132/2023, ADCT arts. 125 to 129, which sets the phase-out of ISS between 2029 and 2032, with extinction in 2033 and replacement by IBS. Planalto
• ABES, Brazilian Software Market, data on the share of foreign software in the corporate market. ABES
• Complementary guide on the channel decision from the buyer's side: cloud-marketplace-latam-guide
• Complementary guide on operating the cloud route for the ISV: how-to-distribute-saas-via-cloud-marketplace

Next step for the international ISV

Route decisions get expensive when they are made twice. The ISV that has already picked the cloud marketplace path can run it with Nexforce executing the channel rather than funding the listing cycle alone, and the ISV that has not committed yet can publish through the regional route and reach buyers in Brazil, Mexico and Colombia under the same contract it already uses in other markets. The practical test takes one deal: take the largest proposal currently in the pipeline, run it through the buyer-side math of this article, and see whether the number that reaches the buyer's finance team fits the budget that was approved. Vendors ready to run that test on a live proposal can map their buyers and payment methods on the Nexforce Marketplace page.