B2B cross-border payments: the ISV guide to LatAm

The question an international ISV asks before selling into Latin America is almost never "how do I charge." It is narrower and more expensive: by which rail does the money from a buyer in Sao Paulo, Mexico City or Bogota reach the seller's account, in what currency, after how many conversions, and what does the company have to open on the LatAm side for that to happen. The market already exists on that side: 73% of the corporate software used in Brazil is foreign, according to ABES. ISVs (Independent Software Vendors, software companies that sell their product to other companies) that enter the region discover that closing the contract was the easy part. The payment is the part nobody designed.

Start with the boundary this guide does not cross. Merchant of record is the model in which one company assumes the fiscal role of the sale: it is the seller in front of the buyer and carries the tax. This piece does not deal with that. It deals with the payment-flow layer, the one that accepts the buyer's money, converts it, settles it and returns it to the ISV without assuming the fiscal role of the sale. The distinction sounds academic until the day finance asks who issues the invoice and who answers for the tax.

The piece covers one named solution: the ISV sells into Latin America through Nexforce's local infrastructure, in local currency and without opening its own fiscal entity. The other route, selling through a cloud marketplace with Nexforce operating that path, exists and will be mentioned in the right place. The axis of this guide is the first path.

What are B2B cross-border payments in Latin America?

B2B cross-border payments, as this guide reads them, are the flow of money between two companies based in different countries, from the buyer's acceptance to settlement with the seller, including currency conversion, withholding, timelines and repatriation. It is not a consumer checkout. It is a chain with identifiable parts.

The difference that decides the cost is not in the transaction size, it is in the number of currencies and institutions the money crosses. A Mexican corporate buyer pays in pesos, on the local rail it already uses. The ISV keeps its books in another currency. Between those two points sit acceptance, conversion, settlement and repatriation, and each stage has an operator and a fee. Anyone who ignores that split treats international billing as an integration problem. Anyone who understands it treats it as a treasury problem.

The territory has a known size: the same 73% from ABES says the local buyer already buys software from abroad. What that buyer does not have is a payment path designed for the purchase.

How does the flow work, layer by layer?

The cross-border B2B flow organizes into five layers: acceptance, conversion, settlement, repatriation and what is withheld along the way. Understanding the order matters because the cost of one layer stays invisible until the previous one is solved, and that sequence separates a designed billing from an accounting surprise at the end of the quarter.

Acceptance first. The LatAm buyer pays by the method it already knows: boleto in Brazil, Pix, local card, domestic transfer. No corporate buyer wants to open an international account to pay for software, just as no finance team wants to explain a dollar expense without an invoice.

Then comes conversion, the point where the money changes currency and carries two costs added together, the operator's spread and the timing of the exchange rate, with an FX lock closing the rate on the purchase date and removing from the contract the exposure between billing and payment.

What remains is settlement, which is not the same as cash coming in. Settlement is the moment the converted money becomes available capital, and not necessarily the moment it enters the seller's cash. A receivable can exist and still not be money. That distinction is where the ISV's working capital is decided, with the models detailed in Cross-border settlement: where to convert.

In repatriation, the money leaves the buyer's jurisdiction and reaches the seller's currency. Here come the institution that conducts the remittance, the settlement timeline and the documentation that supports the operation. A remittance without documentary backing is a problem that shows up months later, when nobody remembers which contract originated it.

The fifth layer is not a stage, it is the sum of what was withheld across all the others. The ISV that prices by looking only at the acceptance fee underestimates the real cost of selling into the region.

Which local payment methods matter?

The local payment methods that decide the LatAm buyer's conversion are few and concentrated: boleto and Pix in Brazil, installment local cards in Mexico and Brazil, domestic transfers in every country. The right method is the one the buyer already uses, not the one the seller knows. Installments enter here as a market practice of the local market, with the mechanism verified in Brazil and the read for the other countries treated as preliminary.

Boleto and Pix carry distinct behaviors. Boleto is a billing document with a clearing window that can reach several days, and that window affects the seller's working capital. Pix settles in seconds and changed the Brazilian corporate payment standard; the recurring version of the rail, Pix Automatico for recurring SaaS payments, matters to anyone selling subscriptions, because it brings billing closer to the contractual recurrence.

The installment local card is the method that confuses outsiders most. In Brazil, installments are a cultural norm, not a concession: the buyer expects to split the payment into as many as twelve installments. The same market behavior is observed in Mexico, treated here as a market under preliminary analysis. The ISV that does not offer installments loses the comparison before price is even discussed. Here the working-capital asymmetry that changes the equation appears. When the local layer pays the ISV up front and installments the end buyer, the layer carries the credit risk, not the seller. The ISV gets paid without carrying a receivable, and the buyer gets the payment term.

Covering those rails country by country, each with its own contract and reconciliation, multiplies operational effort where the ISV holds no competitive advantage. The post Local-currency payments: selling SaaS in Latin America develops that cost cut.

FX and repatriation: where does the money lose value?

FX and repatriation are the two layers where the ISV's money loses value without the transaction changing price. FX is the conversion of one currency into another; repatriation is the movement of value back into the seller's currency. Both carry their own cost, timeline and risk, and neither shows up on the product shelf.

The FX spread is the first place that value is lost. It is the difference between the market reference rate and the effective rate applied in the operation, and it grows when conversion happens across multiple links. A payment that passes through three conversions carries three spreads added together. Reducing the number of conversions cuts the FX cost more than negotiating the rate of one isolated link.

Currency exposure is the second point. Between the billing date and the settlement date, the currency moves, and whoever absorbs that variation is whoever did not lock the rate. An FX lock on the purchase date shifts the uncertainty to whoever can manage it and returns predictability to the contract.

Repatriation adds the documentation layer. International remittances require backing: contract, invoice, proof of the service rendered. An ISV without a process in place discovers the size of the problem at the first accounting close, when it has to explain a remittance nobody classified.

Here the legal-precision mark that governs this sub-line applies. Any analysis of withholding or remittance cost specific to a LatAm country outside Brazil is preliminary in this text. The tax treatment of each jurisdiction requires verification against the country's current legislation and is not asserted here as a conclusion.

Acceptance, orchestration and merchant of record: who does what?

These are three distinct functions the market tends to blur: acceptance moves the buyer's money to the layer; orchestration decides which provider processes each transaction; merchant of record assumes the fiscal role of the sale. Confusing them produces the wrong contracting and the wrong invoice.

Merchant of record is the most misunderstood function. In that model the company stops being a facilitator and becomes the seller in front of the buyer, with responsibility for the tax on the sale. It is a legal role, not a billing feature, with its own treatment in Merchant of record: what it is, when a software company needs it, and how to choose. The layer in this guide is different: it operates the payment flow without assuming the fiscal role of the sale.

Orchestration is the function above the gateway. It neither accepts nor converts; it decides which provider processes each transaction according to cost, acceptance and availability rules, detailed in Payment orchestration: the layer above the gateway. In flow design, orchestration enters where more than one provider competes for the same transaction. Without that condition, it is complexity without return.

Acceptance is where the buyer touches the system for the first time. It is there that the local method, installments and recurrence meet, and it is there that payment friction decides whether the sale closes.

What changes when the ISV sells without opening an entity?

Selling without opening a local fiscal entity changes the nature of the problem: the ISV stops constituting a legal person in LatAm, with accounting, ancillary obligations and capital, and starts operating through a layer that already exists in each market.

Opening an entity in each market means multiplying a fixed cost by country. Before any revenue, the ISV covers incorporation, a local accountant, ancillary obligations and a domestic bank account. For a small contract, that structure never pays for itself.

The local-infrastructure path moves that cost to the layer. Each jurisdiction has its own nexus and withholding rules, and applying them to a specific country requires preliminary regulatory analysis.

The Nexforce Marketplace covers that path with verifiable attributes. The ISV operates with its own standard contract and its own programs, without adopting a third party's paperwork. The layer is cloud-agnostic: transacting requires no commitment to any cloud provider. It is cheaper for the ISV and cheaper for the end client, and the text sustains both statements because they are two. It covers local currency across all of LatAm, not only Brazil, and carries a reseller network.

There is also the software alliance, the least understood differentiator. Nexforce generates savings on the buyer's or prospect's other software spend to make the ISV's deal viable. What closes the deal is the buyer's total software bill, not the ISV's own discount. The list closes with the working-capital arrangement: Nexforce pays the ISV up front and installments the end buyer in up to twelve installments, so the credit risk stays with the layer and the ISV gets paid without carrying a receivable. Finally, the cost to the ISV is zero, there is no minimum deal size and the coverage reaches the entire region.

Direct path, cloud marketplace or the local layer?

The direct path, a cloud marketplace and the local layer solve the same problem with different economics. On the direct path, the ISV sells and bills on its own, which requires a receiving fiscal entity, settlement in foreign currency and its own receivable. On a cloud marketplace, a third party lists the product and imposes its contract, its program and its per-transaction fees.

The direct path charges for freedom with structure. With no intermediary, the ISV controls the commercial relationship and the pricing policy, but carries the fiscal entity in the buyer's country, receivables management, repatriation cost and continuous compliance in each market. For anyone entering, it is the sum of all the costs this guide just decomposed, paid before the first sale.

The cloud marketplace trades structure for adherence to someone else's standard. The listing goes through a review cycle, the marketplace's contract and program are imposed on the seller, and each transaction carries a fee, with settlement in foreign currency. The inventory of channels and frictions on that path is in Cloud Marketplace LatAm: channels, partners and compliance. When chosen, it is one of the two solutions Nexforce operates for the ISV, not the axis of this guide.

The local layer proposes another arrangement: the ISV sells into LatAm through Nexforce's infrastructure, receives in local currency, and the buyer pays on the rails it already uses, with installments in up to twelve payments and an FX lock on the purchase date. The cost of the adjacent tax layer, which in Brazil has its own track in Cost of selling software in Brazil: fees, taxes and the bill, is not the subject of this pillar.

The choice is between buying structure to control and renting adherence to enter. The direct path serves whoever has already decided LatAm is a permanent market. The cloud marketplace serves discovery. The local layer serves whoever wants revenue in the region without building the payment operation from scratch.

Common mistakes when structuring payments in LatAm

The most expensive mistakes in structuring B2B cross-border payments come from treating billing as an integration detail. They appear in a predictable sequence, and the first contaminates the ones that follow.

1. Pricing by the visible fee. The acceptance fee is the only part of the cost that tends to be in the commercial proposal. FX spread, settlement fee and remittance cost do not appear, and that is why they add up to a surprise at the quarterly close.
2. Ignoring installments as a requirement. In markets where installments are the norm, not offering them eliminates the seller from the comparison before price.
3. Confusing acceptance with settlement. Accepting the buyer's payment does not mean having the capital available. The gap between the two is the ISV's working capital, and treating it as zero distorts the cash projection.

The interaction between those mistakes is what makes the operation more expensive, because the pricing mistake hides the FX and documentation ones, and each shows up only at the following close, when fixing the previous one already costs more than designing the entire layer from the start would have.

1. Not locking the exchange rate. Foreign-currency revenue stays exposed between billing and settlement, and the period's variation becomes a financial result of a commercial operation.
2. Leaving remittance documentation for later. Repatriation without documentary backing is a liability that shows up late, when there is no one left to reconstruct the origin of the operation.
3. Assuming one country's method works for another. Pix, boleto, local card and domestic transfers have distinct behaviors and timelines in each market. Treating LatAm as a single payment market is the mistake this pillar exists to correct.

Frequently asked questions about B2B cross-border payments

What separates B2B cross-border payment from consumer payment? B2B cross-border payment involves two identified companies, larger amounts, contracts and fiscal documentation, while consumer payment is anonymous and low-value. The B2B layer has to handle invoices, remittance backing and accounting reconciliation, requirements a consumer checkout does not carry.

What is merchant of record and why is it not the same thing as this layer? Merchant of record is the model in which a company assumes the fiscal role of the sale, being the seller in front of the buyer and answering for the tax. The payment layer described here operates the financial flow without assuming the fiscal role of the sale. They are different legal functions.

Does the ISV need to open a fiscal entity in Latin America to get paid? Not necessarily. Selling through local infrastructure, the ISV receives in local currency without opening its own entity in the region. Each jurisdiction has its own nexus and withholding rules, and applying them to a specific country requires preliminary regulatory analysis.

How do installments in up to twelve payments affect the ISV's cash? When the local layer pays the ISV up front and installments the end buyer, the credit risk stays with the layer and the ISV does not carry a receivable. The seller gets paid without waiting for the buyer's term, and the buyer keeps the installments the market expects.

Why does the FX spread weigh more than it looks? Because each intermediate conversion adds its own spread. A payment that crosses three conversions carries three overlapping costs. Reducing the number of conversions reduces the total cost more than negotiating the rate of one isolated link.

Further Reading and References

• Nexforce Marketplace: acceptance, FX, settlement and repatriation layer for the ISV selling into Latin America.
• How to sell SaaS software in Latin America: the international ISV map: the umbrella pillar for the ISV in the region.
• Cross-border settlement: where to convert: the conversion and settlement models in detail.
• Merchant of record: what it is, when a software company needs it, and how to choose: the fiscal role of the sale and its criteria.
• ABES, the Brazilian software market: source of the data point that 73% of corporate software in Brazil is foreign.

Where to start structuring payments in LatAm

The starting point is not choosing a provider, it is designing the layer. The ISV that decides to sell into Latin America has to answer five questions in the order they appear: how the buyer pays in its own country, how the value is converted and when the rate is locked, when the money becomes available capital, how the remittance is documented and repatriated, and how much all of it costs beyond the acceptance fee. The answer to those five questions is the design of the layer.

The Nexforce Marketplace exists to be that layer. The ISV operates with its own standard contract and its own programs, the layer is cloud-agnostic, it is cheaper for the ISV and for the end client, it covers local currency across all of LatAm, it includes a reseller network and it uses the software alliance to make the deal viable from the buyer's total software bill. The cost to the ISV is zero, there is no minimum deal size, and Nexforce pays the ISV up front while installment-planning the end buyer in up to twelve payments.

For the international ISV, the decision to enter LatAm stops being a bet on structure and becomes a channel decision. Anyone who wants to start without opening a local entity can look at the Nexforce Marketplace and map the first contract in the region before constituting any operation of its own.