International SaaS payments in Latin America

A charge can clear in the buyer's country and still leave the international ISV without an answer on who settles, in which currency it receives and which documents travel with the payout. The local method solves only one layer. International SaaS payments connect collection, settlement, conversion, tax responsibility and reconciliation.
The reader is the ISV (Independent Software Vendor, a software company that sells its product to other companies) that wants to collect from customers in Latin America without opening a tax entity in every jurisdiction. What is at stake is margin, cash predictability and the ability to close a deal the buyer already decided to buy. Volume, method and route vary with the concrete contract; this guide does not invent one transaction to stand for every market.
Reference date: The Brazilian tax references in this guide follow the state consolidated in the Distribution Counsel corpus on 06/07/2026, reviewed for this analysis on 06/08/2026. Validity after 06/07/2026 must be confirmed before a decision, especially around the CBS and ISS transitions. The regulatory analysis for Mexico, Argentina, Colombia, Chile and Peru remains preliminary and requires local confirmation before signature.
In short: regional collection must connect local method, settlement, FX, documentation and reconciliation. For the international ISV still validating the region, the recommendation is to start with a regional route that offers local currency, clear contractual rules and country-level tax validation. This guide covers collection and receiving by the ISV. It does not replace legal or tax advice and does not claim that a local method alone resolves registration, withholding or payout.
What are international SaaS payments for ISVs?
Cross-border payment is, in this guide, the operational equivalent of international SaaS payments: the local buyer pays in its currency and the international ISV receives in another, after collection, settlement, FX and tax controls. The operation must resolve four points: local method, conversion, payout and documentary responsibility.
The term sounds financial, but the question starts in sales. The Brazilian buyer should not have to adapt its accounts-payable process to the international ISV's bank. The international ISV, in turn, should not discover in month three that the conversion rate, the payout term and the applicable withholding changed the contracted margin.
The position of this guide is direct: for an international ISV testing the region, one regional arrangement with local currency and payment is better than five independent integrations. Scale decides. Independent integrations start to make sense when volume, tax staff and country-level predictability justify separate administration.
Main decisions for the international ISV
The first decision is commercial, but it produces operational effects: the ISV needs to know which method the buyer accepts and which route will get the money to the ISV. Then it must lock the points that change margin and timing.
- Collection: which methods the buyer actually uses in the country.
- Settlement: in which currency and in how many days the ISV receives.
- FX: this is where the risk sits. Who absorbs the spread and the variation between purchase and payout?
Documentation comes next. The contract must identify the party that sells, invoices and answers for local obligations. Finally, the scale choice compares independent integrations with regional infrastructure.
How does the money move before it reaches the ISV?
The flow has five stages: the buyer chooses a local method, the payment is authorized, the amount is settled in local currency, conversion follows the contracted rule and the ISV receives the payout. Each stage can create delay, cost or an obligation. That is why the analysis must follow the transaction, not only the checkout screen.
- Method choice. The buyer sees PIX, boleto, a local card, a bank transfer or an equivalent method in its country.
- Authorization and collection. The operation confirms the payment and records the order, the contract and the buyer's cost center.
- Domestic settlement. The money enters the local rail, in real, peso, sol or another buyer currency.
- Conversion and payout. The quote, the spread, the term and any withholdings must be defined before the sale.
- Reconciliation. The ISV reconciles contract, local payment, fee, FX and the amount received in its account.
The fifth stage is often forgotten. An approved payment is not the same as a reconciled receipt. An ERP can show the sale at the contracted price while the bank account receives another amount, on another date and with another description.
Which local methods does the buyer use in each country?
International SaaS payment methods vary by country and provider. In Brazil, the Central Bank documents PIX. SPEI is Mexico's interbank infrastructure. In Colombia, PSE requires route confirmation. Chile and Peru require validation. The table is a verification map, not a statistic. Detail changes settlement for the international ISV.
| Market | Methods the ISV should evaluate | What changes in receiving | Operational question |
|---|---|---|---|
| Brazil | PIX, boleto, local card and installments | Local currency, settlement and eventual conversion to the ISV currency | Who sets the quote and reconciles the payment? |
| Mexico | SPEI and other methods offered by the provider | SPEI is interbank infrastructure; availability and confirmation depend on the contracted route | Does the buyer receive instructions its treasury recognizes? |
| Argentina | Local methods confirmed in the commercial proposal | FX controls and regulatory changes require current validation | Does the contract define currency, reference date and payout? |
| Colombia | PSE and other methods offered by the provider | In Colombia, PSE is a bank-debit method whose availability for the concrete commercial route must be confirmed with the provider and with the applicable Colombian official source on the operation date. | Does the chosen method settle into the structure the ISV uses? |
| Chile | Local methods confirmed in the commercial proposal | Tax documentation for the digital service has its own rule | Who tracks the applicable registration and collection? |
| Peru | Local methods confirmed in the commercial proposal | Official guidance must be checked before promising a collection form | How is the receipt tied to the correct invoice? |
The Central Bank of Brazil describes how PIX works and publishes its statistics. SPEI is Mexico's interbank transfer infrastructure, but its availability for international SaaS payments depends on the provider and the contracted route. In Colombia, PSE is a bank-debit method whose availability for the concrete commercial route must be confirmed with the provider and with the applicable Colombian official source on the operation date. That reference does not prove that a specific transaction can be settled by any partner.
The difference shows up in the detail. PIX is domestic, while SPEI is a Mexican interbank system. Showing a method at checkout does not prove that the operation is enabled for the chosen beneficiary, contract or settlement account. The account, the documentation and the FX route must be connected.
How do Brazil, Mexico and Argentina work for an international ISV?
Brazil, Mexico and Argentina ask different questions of the international ISV. The route changes. In Brazil, collection method and outbound remittance are separate analyses. In Mexico, collection does not replace tax verification. In Argentina, conversion and payout depend on the rules in force. The rule must be confirmed before the international ISV promises term, currency or documentation.
Brazil: a local method does not remove the tax analysis
PIX solves domestic collection. Collection is one layer. It does not, by itself, resolve the classification of the operation that takes the money abroad. When the payment involves SaaS or a technical service, the analysis must separate the contract from the collection method.
In CLIENT mode, under the state of the law verified through 06/07/2026 in the legal corpus, when a Brazilian company contracts SaaS or a technical service directly from a foreign supplier, the general reference is IRRF at 15% (RIR/2018, arts. 765 and 767), CIDE at 10% under the applicable classification (Law 10.168/2000, art. 2, paragraphs 1-A and 2; SC Cosit 191/2017), PIS/COFINS-Import at 9.25% on the service component (Law 10.865/2004, arts. 7 and 8; IN RFB 2.121/2022, art. 273), ISS from 2% to 5% depending on the municipality (LC 116/2003, arts. 1, paragraph 1, 6, paragraph 2, I, 8, II and 8-A) and IOF-FX at 3.5% (Decree 6.306/2007, art. 15-B, XXIV, as amended by Decree 12.499/2025). Treaties may change IRRF only when the applicable instrument, the beneficiary's jurisdiction and the corresponding article are verified. Also see RIR/2018, Decree 9.580/2018, Law 10.168/2000, Law 10.865/2004, LC 116/2003 and Decree 6.306/2007. These rates are a dated CLIENT-mode reference, not a universal rate for every software payment.
Classification is not automatic: a pure license, segregated and without technology transfer, is an exception to CIDE and, on the license component, does not enter the PIS/COFINS-Import base; a hybrid contract that is not segregated or that includes related services requires analysis of the whole and of the service component.
CIDE has an essential distinction: the 10% CIDE applies to SaaS and technical services when that is the classification applicable to the contract; the exemption in paragraph 1-A of art. 2 of Law 10.168/2000 applies exclusively to pure software licenses without technology transfer. Consultation Solution Cosit 191/2017 supports, for the facts it examined, the classification of SaaS as a technical service and the 10% levy. It is an administrative interpretation of the Federal Revenue, binding on the administration within its scope, not a judicial precedent and not a universal rule detached from the facts. SC Cosit 99/2018 addresses the inclusion of IRRF in the CIDE base and is not used here as authority to classify SaaS.
For the 2026 horizon, LC 214/2025 provides a test year of CBS at 0.9% and IBS at 0.1%, with the compensation rules set in the law itself. That transition reference does not replace, in 2026, the current-law formulas for PIS/COFINS-Import; PIS/COFINS are extinguished in 2027 by LC 214/2025 and give way to the transition into CBS under the applicable rules. The future full CBS rate depends on the applicable resolution and must not be presented as a binding 28%; any 28% is only a planning hypothesis, if used. ISS enters transition from 2029 to 2032 and is extinguished in 2033, under EC 132/2023. Legislation and the corpus must be rechecked before a multi-year decision.
The analysis above is CLIENT mode. The ISV must validate contract, tax residence, documentation and responsibilities before pricing. A double-tax treaty does not automatically change IRRF, CIDE, PIS/COFINS-Import or ISS; any reduction or allocation rule depends on the beneficiary's country, the domestic implementing act and the article applicable to the income.
For the international ISV, the consequence is commercial. A proposal in dollars may not represent the total cost for the Brazilian buyer, and a discount given by the ISV may be applied to the wrong problem. The contract must say who calculates, who collects and which event determines the net amount.
Mexico: local collection and tax are separate questions
In Mexico, the ISV must separate "how does the buyer pay?" from "who registers and remits the tax?". SPEI is Mexico's interbank transfer infrastructure, identified by Banco de México on the official SPEI page; availability for the concrete route must be confirmed with the provider. Treatment of digital services supplied by non-residents depends on the type of service, the buyer and the rules in force, which must be checked directly with SAT. Because the Distribution Counsel corpus has no Mexican legislative folder, this regulatory analysis is preliminary. In the corpus, there is no support; verification must be routed to Distribution Counsel or local counsel before signature.
The SAT institutional page offers the official reference for the Mexican framework. It is not safe to turn a rate or procedure from one category into a rule for every SaaS contract. The international ISV should ask the buyer and local counsel to confirm the tax document, the withholding and the registration obligation that apply to the case.
The operational point remains: the buyer wants a payment instruction its treasury recognizes. A regional route can deliver that experience without forcing the ISV to build a Mexican banking integration before demand is validated.
Argentina: the contractual term must survive FX
In Argentina, the critical variable is not only the payment method. It is the ability to convert and pay out the amount on the date and in the currency agreed. The Central Bank of the Argentine Republic maintains the foreign-exchange and external rules; the specific legal-framework page must be located and checked on the operation date, because the address previously cited was not reachable on 06/08/2026. The applicable rule changes with the nature of the service, the payer and the moment of the operation. The Distribution Counsel corpus has no Argentine legislative folder. Therefore, this regulatory analysis is preliminary. In the corpus, there is no support; verification must be routed to Distribution Counsel or local counsel.
That is why the proposal must clarify collection currency, quote date, payout term and treatment of an FX restriction. The article does not set percentages for VAT, income tax or FX tax because those numbers depend on force and scope. The Argentine regulatory analysis here is preliminary and requires local validation before signature.
Collecting in local currency can reduce buyer friction. Receiving without a conversion rule can move the same friction onto the ISV's margin. The contract must resolve both sides.
What changes in Colombia, Chile and Peru?
Colombia, Chile and Peru are not one collection market. PSE requires confirmation with the provider and the applicable Colombian official source; Chile has its own guidance for digital services of non-residents; SUNAT gathers Peruvian guidance. Method availability and tax rules in these countries are preliminary analyses in this regional guide.
In Colombia, PSE is a bank-debit method whose availability for the concrete commercial route must be confirmed with the provider and with the applicable Colombian official source on the operation date. The Distribution Counsel corpus has no Colombian legislative folder. This regulatory analysis is preliminary. VAT, withholding or income-tax incidence requires consultation of DIAN and local verification, considering contract, service and the status of the international ISV.
In Chile, SII maintains institutional guidance on digital services of non-residents, and the applicable rule, Law 21.420 and its amendments, must be checked in the text in force on the operation date. The international ISV must confirm whether the operation requires registration, collection by the non-resident or another form of compliance. The Distribution Counsel corpus has no Chilean legislative folder. This regulatory analysis is preliminary and requires local validation.
In Peru, SUNAT gathers the official guidance, and the international ISV must verify treatment of the service and the payment before promising a route. The Distribution Counsel corpus has no Peruvian legislative folder. This regulatory analysis is preliminary. In the corpus, there is no support; verification must be routed to Distribution Counsel or local counsel. A wallet or voucher may be evaluated for collection, but it does not alone decide tax responsibility.
That distinction is decisive for the ISV: payment method is a product choice; tax obligation is a legal conclusion on facts. Mixing the two produces a commercial promise operations cannot sustain.
When is a local partner better than country-by-country integrations?
A local partner is better when the international ISV does not yet have the volume, staff or economic reason to run an operation in each country. Before price, it should identify the legal model of the route. Processor, agent, merchant of record or reseller do not alone define who sells, invoices or answers for taxes. The contract assigns each function by jurisdiction.
The advantage is not "eliminating taxes". It is reducing the number of interfaces the international ISV must administer, without hiding obligations that still require validation. A payment route does not, by itself, establish tax residence, permanent establishment, local registration, withholding or responsibility for indirect tax. The obligation remains.
The direct alternative requires different contracts, integrations, accounts, payout calendars and reconciliations. It also leaves the international ISV alone to decide how the buyer pays in each market. For five countries, complexity does not grow only with the number of APIs. It grows with the number of combinations among currency, term, documentation and exception.
On a cloud-marketplace path, the ISV still faces listing and review cycles, fees on every transaction, the contract and programs imposed by the marketplace, a cloud commitment to transact, a possible foreign tax entity, dollar settlement with FX and repatriation cost, and compliance carried by the ISV itself. That is the friction of the direct path before any comparison with a regional route. The cost appears across several interfaces.
Nexforce Marketplace serves the international ISV through two distinct solutions: sell in Latin America on Nexforce local infrastructure, or sell through a cloud marketplace with Nexforce running that route. This article covers the first solution, regional receiving on local infrastructure. That is a commercial statement of the Nexforce model, not a conclusion on tax residence, permanent establishment, local registration, withholding or indirect tax.
In this first solution, the international ISV sells in Latin America on Nexforce local infrastructure. The commercial proposal includes local methods, local currency, upfront payment to the ISV and buyer installments of up to 12 months, subject to applicable conditions. The concrete contract documentation defines the parties, the collection functions and the tax allocation in each jurisdiction. Regional infrastructure alone does not prove that the international ISV needs no local entity or registration. That consequence requires validation by jurisdiction.
In the described solution, Nexforce Marketplace works with the ISV's standard contract and programs, without requiring the commercial process to be rebuilt. It is cloud-agnostic, charges no business minimum and charges no cost to the ISV. For the buyer, the commercial offer includes regional methods such as PIX, boleto, local cards and installments. For the ISV, the proposal provides upfront payment and buyer installments of up to 12 months, subject to applicable commercial conditions.
The other differentiators are also economic. The commercial offer provides local currency across Latin America, a reseller network and a software alliance that can generate savings on other client spend to enable the ISV purchase. Those attributes do not determine tax incidence, licensing, registration, withholding or tax responsibility. The contract and the structure of the operation must say what belongs to each party.
In CLIENT mode, the Brazilian buyer imports directly and must analyze its tax layer. In the regional solution, distribution and receiving depend on the concrete contract documentation, which remains indispensable. Contractual and tax allocation must be validated for each jurisdiction. CLIENT-mode criteria cannot be transferred automatically to the regional solution.
How should you choose the receiving route before the first contract?
The choice should be made before the commercial proposal, using the first contract as an operations test rather than improvisation. Start small. The ISV needs to compare local method, conversion cost, payout term, documentation, support and scale. If the answer does not fit on one page for finance, the route is not ready yet.
- Map the buyer. Record country, currency, required method, payment term and the system used by treasury.
- Classify the contract. Separate pure license, SaaS, technical service and other components before estimating withholdings.
- Define settlement. Write currency, quote, spread, reference date, term and who bears the cost.
- Test reconciliation. Run a controlled transaction and compare contract, local receipt, payout and the ISV statement.
- Compare structures. Place independent integrations, a regional partner and the Nexforce Marketplace solution side by side, using the same countries and the same term.
- Scale only after proof. A dedicated entity should enter when volume covers its tax, banking and reconciliation staff.
The recommended decision for the first regional cycle is to start with a route that accepts local currency and methods, records the applicable FX conditions and delivers verifiable reconciliation. The ISV buys operational learning without turning every sale into an infrastructure project.
What is the cost of receiving in local currency?
The cost of international SaaS payments is not a single percentage. It combines collection, FX spread, term, working capital, reconciliation and tax obligations. Compare CLIENT mode, with direct import by the Brazilian buyer, to the regional distribution and receiving solution. Do not add the regimes together or assign buyer or distributor obligations to the ISV.
An honest proposal separates those items and states what can vary. Without that breakdown, receiving in local currency is a promise without a price.
The real cost appears when payout term, spread, responsibility for withholdings and the cost of capital sit in the same account before signature.
Spread is the difference between the reference quote and the effective rate. FX weighs. An FX lock, when contracted, fixes the quote at a defined moment. They are different mechanisms. The first measures the price of conversion. The second reduces exposure between sale and payout.
The ISV also needs to look at the calendar. A buyer that pays today and an ISV that receives fifteen days later create exposure that does not appear in the gateway rate. In installments, the risk repeats at each due date unless the contract sets another rule. Term changes the math.
Nexforce Marketplace presents local collection and upfront payment to the ISV as elements of the commercial proposal. The ability to fix FX conditions, when offered, must be confirmed in the applicable contract; upfront payment is not automatically an FX lock. The advantage should be measured only against the concrete operation: country, currency, term, method, volume and responsibilities. The article does not invent a percentage saving because there is no universal number for that comparison.
Which mistakes make payment fail after the sale?
The most expensive mistakes happen when sales close the contract without involving finance and compliance. The buyer discovers it cannot pay with the promised method, the ISV discovers it will receive on a different date and the team tries to fix documentation after the sale is already signed. Prevention is a process decision, not a collections campaign.
The first failure signals appear before settlement. The method was promised without confirming the settlement route. Latin America was treated as one currency, one tax and one calendar. A regional rate appeared without country, service, base or force date.
Then the problem reaches reconciliation and the contract. An approved payment is not money available in the ISV account. A partner without written responsibilities leaves reconciliation for later, when the sale is already signed. Discounting to offset a tax cost that is not yet classified only moves uncertainty onto the ISV's margin.
The central mistake has a name. The contract describes the price, but not the path of the money. The international ISV needs to sell the product and the way it gets paid as one commercial operation, with currency, date, document and owner identified.
FAQ: how do ISVs receive international SaaS payments in Latin America?
The international ISV must treat collection and receiving as one operation. Local method, settlement, FX, contract, documentation and reconciliation form the money route. Regional infrastructure can reduce integrations, but it does not alone define tax responsibility or replace legal validation in each country.
Does an international ISV need to open an entity in every country?
Not necessarily. The need depends on the contract, the activity, the country and the collection model. Regional infrastructure can support local collection without the ISV opening its own entities, but the legal and tax structure must be confirmed for each jurisdiction.
Can the ISV receive PIX directly into a foreign account?
PIX is a Brazilian domestic system. Whether an international ISV can receive on that route depends on the participating institution, the account used and the contract. Showing PIX at checkout is not enough to conclude who receives, who converts or who pays out. The operation needs a local route and a clear rule to convert and pay out the amount.
Is SaaS exempt from CIDE in Brazil?
SaaS should not be treated as a pure license. The 10% CIDE applies to SaaS and technical services when that is the classification applicable to the contract, under the facts examined in Consultation Solution Cosit 191/2017. The exemption in paragraph 1-A of art. 2 of Law 10.168/2000 is exclusive to pure licenses without technology transfer.
How should the ISV compare spread and an FX lock?
Spread is the difference between the reference and the effective rate. An FX lock fixes the quote according to the event defined in the contract. The ISV should compare rate, payout term, installments and responsibility for variation, not only the percentage shown at checkout.
Does Nexforce Marketplace charge the ISV?
The product reference states that there is no cost to the ISV and no business minimum. The commercial proposal must record the conditions applicable to the case and explain local methods, upfront payment to the ISV and buyer installments of up to 12 months.
To connect this guide to published content, also read how to avoid chargebacks in cross-border SaaS, when to hire a software distribution marketplace, how to distribute SaaS via a cloud marketplace and the Nexforce Marketplace page. Those pieces cover collection risk, distribution and commercial infrastructure, while this guide concentrates on the payment path through to the ISV's receipt.
References and Further Reading
These sources support the distinction among international SaaS payment infrastructure, tax rule and commercial proposal. Foreign-authority pages are starting points for local validation. They are not opinions on Mexico, Argentina, Colombia, Chile or Peru. Brazilian references are dated so that a normative transition is not read as a permanent rule.
Official sources first.
For payment rails, consult PIX and the statistics of the Central Bank of Brazil, the SPEI page at Banco de México, whose availability for the concrete route depends on the provider, and confirm PSE with the provider and with the applicable Colombian official source on the operation date.
On the Brazilian tax front, the official sources are RIR/2018, Decree 9.580/2018, Law 10.168/2000, Law 10.865/2004, LC 116/2003, Decree 6.306/2007, LC 214/2025 and EC 132/2023. Consultation Solution Cosit 191/2017 must be read with the facts and the classification of the contract. SC Cosit 99/2018 is a separate reference for the CIDE base when the concrete case concerns inclusion of IRRF.
For preliminary regulatory research outside Brazil, consult the portal of the Central Bank of the Argentine Republic, where the legal framework for foreign exchange and external operations must be located on the consultation date, DIAN, Chile's SII and Peru's SUNAT. Analysis of those countries requires Distribution Counsel or local counsel.
The commercial reference is Nexforce Marketplace, a solution for international software in local currency. Its commercial attributes do not replace verification of the contractual, tax and regulatory structure.
The ISV's next decision
Before signature, the ISV needs to answer five questions: who collects, in which currency, on which term, by which route and under which documentary responsibility. The answer must also identify the seller, the invoice issuer and the party responsible for withholdings and indirect taxes. Without that sequence, the local method remains incomplete.
Order matters. First, the contract defines each party's function; then operations tests method, settlement and reconciliation; finally, the ISV compares cost and scale. Regional infrastructure can reduce initial complexity, but it does not replace the legal analysis of each country or turn a commercial statement into a conclusion on tax residence or tax obligation.
The next step is documentary.
Explore Nexforce Marketplace to evaluate the regional receiving route, local methods and the structure of upfront payment to the ISV.

Sell software in Latin Americawith no setup and saving 50%
Distribute your SaaS through the Nexforce platform scaling sales channels in a simple way
Run SimulationRelated articles

Merchant of Record Brazil: ISV Guide to Sell SaaS Locally
Complete guide to the Merchant of Record model for international ISVs selling SaaS in Brazil and Latin America without opening a local fiscal entity.
Read more
How to Sell SaaS in Latin America Beyond Cloud Marketplaces
A guide for international ISVs who discovered that the cloud marketplace shuts the door on Latin America. The real path to selling SaaS in the region, with local currency, local invoicing, and zero foreign entity.
Read more
Cross-Border SaaS Chargeback Prevention: A Guide for ISVs
A practical guide for ISVs preventing chargebacks on Latin American SaaS sales. Strategies by payment method, country-specific dispute rules, and how to reduce cross-border friendly fraud.
Read more