How to create a SaaS procurement policy in LatAm

The SaaS subscription left the team chat and landed on finance’s invoice three months later. Nobody lied in the process. What was missing was a written rulebook: who approves, with what evidence, in which currency, and with which invoice. A SaaS procurement policy closes that gap before auto-renewal and shadow IT run the numbers on their own.

What is a SaaS procurement policy and why does a LatAm company need one?

A SaaS procurement policy is the internal document that sets scope, approval tiers, TCO, security, vendor risk, currency, invoice form, and renewal rules before anyone signs. In Latin America, the real cost of foreign software often rises 50% to 70% above list price; without a policy, the team buys from the catalog and finance discovers the cash outlay at month-end close.

The ABES/IDC study Brazilian Software Market: Overview and Trends (2025 edition) describes a market in which most corporate software consumed in Brazil is foreign-origin. That figure is not market trivia. It describes the buyer’s routine: the quote arrives in dollars, the contract sits under foreign law, the invoice is not a domestic tax document, and renewal runs on a card belonging to someone who already left the company. The policy does not erase the friction. It decides, in writing, who carries each piece of it.

In practice, a SaaS procurement policy answers five questions the team chat never answers with rigor: what falls under the rulebook, who decides, what it really costs, which documentation is required, and what happens at renewal or offboarding. The rest of this piece builds that rulebook in executable steps, from the contracting company’s perspective.

What prerequisites does the company need before writing the policy?

Before the first paragraph of the policy, the company needs four minimum pieces: a named document owner, a map of SaaS spend already in use, a definition of the tax regime, and access to live contracts. Without that package, the text becomes a statement of intent. With it, it becomes an operation the intake form can run every day.

Gather the minimum below before Step 1:

1. Named owner. One role, not a committee. CFO, head of procurement, or controller with a written mandate to publish and revise the policy.
2. Inventory of SaaS in use. Product name, internal owner, annual value, currency, renewal date, payment method, and whether a domestic tax invoice exists.
3. Company tax regime. In Brazil, Lucro Real or Lucro Presumido changes what the policy may promise on PIS/COFINS credit. Only Lucro Real under the non-cumulative regime credits 9.25% against an inbound domestic tax invoice. Lucro Presumido does not credit inbound invoices; the operational gain for that regime is local currency, invoices in reais, FX lock, and less friction in finance. In force in 2026: the 9.25% PIS/COFINS credit on a domestic invoice applies to companies that file under the non-cumulative regime (Lucro Real). Under Complementary Law 214/2025, PIS/COFINS (including Import) expire in 2027 with CBS; ISS phases out from 2029 to 2032 and ends in 2033, replaced by IBS/CBS with credit for the business purchaser. The policy must schedule a review of the credit criterion when the company migrates its consumption-tax regime.
4. Existing financial approval tiers. The SaaS procurement policy fits inside the general purchasing policy. It does not invent a second org chart.
5. Named contacts in information security and legal. Even when volume is low, security and legal enter the flow with objective criteria, not with opaque vetoes.

Companies with fewer than 15 tools and annual spend below an internally defined threshold still need a policy. Size changes how complex the tiers are, not whether a rulebook is required. Shadow IT grows in a small team with a loose corporate card as easily as it grows in a multinational.

How do you build a SaaS procurement policy in eight steps?

The method has eight steps: set scope, fix RACI and approval tiers, classify vendor risk, require TCO before approval, define the security floor, decide currency and invoice form, choose the contracting route, and close renewal and offboarding. Each step produces an artifact. At the end, the policy is the set of those artifacts signed by leadership.

Step 1: Define the scope the policy governs

Scope defines which software-as-a-service purchases fall under the rulebook and which stay outside. Without a clear border, the team debates whether a US$12-per-month plugin needs approval, and the CFO loses the argument on the wrong detail.

Include in scope, by default, four classes intake can recognize without debate:

• Any recurring cloud software subscription paid by card, boleto, PIX, or cross-border remittance.
• Trials that require a card or that convert automatically into a paid plan.
• Add-ons, extra seats, and plan upgrades inside an existing contract when they exceed a share of base value (for example, 15%).

Free tools that process personal data or customer data also enter. They generate no invoice, but they generate privacy risk and data leaving the company without an owner.

Exclude by criterion, not convenience: on-premise software with its own CAPEX may follow the asset policy; one-off professional services without ongoing login may follow the services policy. The practical test: if there is auto-renewal or named seats, it is in scope.

Publish the scope on one page. Teams that do not know whether a purchase “counts” invent shortcuts.

Step 2: Fix RACI and approval tiers

RACI and tiers turn “someone in finance needs to see this” into names, amounts, and deadlines. A SaaS procurement policy dies when approval depends on who is online in Slack.

Define four minimum roles:

Tiers in bands, not exceptions. A common mid-market LatAm design:

1. Up to US$3,000 per year or local-currency equivalent: area manager plus inventory registration.
2. From US$3,000 to US$25,000 per year: procurement or finance plus security (short checklist).
3. Above US$25,000 per year or sensitive data (PII, payments, health, minors): lean committee (finance + security + legal) with a hard maximum of five business days.

The exact numbers belong to the company. What the policy cannot leave open is a ceiling without an owner and a deadline without a clock. A stalled request becomes a personal-card purchase “just for now.”

Step 3: Classify vendor risk before price

Vendor risk comes before the discount. A low price with a lock-in clause, no DPA, and support only in a U.S. time zone at 3 a.m. local time is not savings. It is a deferred bill.

Build a simple risk grid with four axes and objective scoring:

1. Concentration and continuity. Is the vendor unique in a critical process? Is there a documented plan B?
2. Data. Which data enter the tool? Where do they sit? Are there subprocessors?
3. Contract. Governing law, forum, SLA, audit rights, data exit in a readable format, price-change notice.
4. Commercial health. Time in market, public incident history, dependence on a single product.

ISVs (Independent Software Vendors, software companies that sell their product to other businesses) enter that grid the same way large platforms do. Logo size does not replace a DPA. For cross-border purchases, add a fifth axis: ability to issue tax documentation the buyer’s country can use, or to operate through a local route that delivers that documentation.

The policy sets the floor: high risk requires written mitigation (reduced data scope, mandatory SSO, exit clause, vendor cyber insurance when applicable) before the financial tier.

Price does not buy a risk exception.

Step 4: Make TCO an approval criterion, not an optional slide

TCO (total cost of ownership) stops being finance’s spreadsheet and becomes a required field on the request. The policy does not teach every tax line rate by rate; it requires that the number presented to the approver be real cash outlay, not list price, and that the requester know which contracting route supports that number.

On the request, the requester or finance fills at least the block below. Three fields open the conversation; the rest close the outlay:

• Annual list price and original currency.
• Seats, contractual minimum, and overage policy.
• FX estimate and spread when billing is in foreign currency.

When the Brazilian buyer’s direct route includes a remittance abroad, the TCO account must, under the standard classification of SaaS as a technical service, at least provide for IRRF, CIDE (10%), PIS/COFINS-Importação (9.25%), municipal ISS, and IOF-FX (3.5% on service/royalty remittances); calculation detail belongs in the TCO dossier and in the total-cost article, not in the body of the policy. The 10% CIDE applies to SaaS and technical services under the Federal Revenue reading in SC Cosit 191/2017 and Law 10.168/2000; the §1°-A exemption of art. 2 of Law 10.168/2000 applies only to pure software licenses without technology transfer, a category distinct from SaaS.

Add internal implementation, training, and integration cost, plus exit cost (data export, tool overlap during transition).

Calculation detail and route simulations live in how to calculate the total cost of foreign SaaS. Here the policy rule is different: without a completed TCO, there is no approval. Anyone who presents only catalog price returns the request.

For companies on Lucro Real, the policy may require that TCO show whether a path with a domestic tax invoice supports 9.25% PIS/COFINS credit. That credit anchors on the domestic invoice from the local path, not on generic talk of “import with credit.” For Lucro Presumido, the policy does not promise credit; it promises cash predictability and documentation in reais. In both regimes, the policy’s credit criterion must carry a review date aligned with the LC 214/2025 transition (PIS/COFINS and PIS/COFINS-Importação expire in 2027 with CBS; ISS phases from 2029 to 2032).

Step 5: Set the security and privacy floor

Security in a SaaS procurement policy is a binary checklist at the gate, not a workshop after go-live. The technical reviewer marks yes or no. Gray becomes a documented exception with a remediation deadline.

Minimum recommended checklist for any tool that touches customer data or non-public internal data. The first three items block most operational risk:

• Corporate SSO (SAML or OIDC) available on the quoted plan, not only on an unreachable enterprise tier.
• User provisioning and deprovisioning (SCIM or an equivalent process with a named owner).
• Signed DPA, with subprocessors listed and data location declared.

The rest closes the audit dossier: encryption in transit and at rest; exportable access logs or retention compatible with the internal audit window; incident notification process with an explicit deadline.

Low-risk tools (no PII, individual use, non-sensitive data) may run a reduced checklist. The policy names who classifies data risk: information security, not the requester excited about the trial.

Step 6: Decide currency, invoice, and tax documentation on the request

Currency and invoice form decide whether finance can close the month without hunting a card PDF. The policy treats documentation as a purchase criterion, not a post-signature detail, because on the request the route can still change without exit cost.

Three practical rules for the contracting company in LatAm, with normative depth in Brazil and operational friction across the rest of the region:

1. Preference for local-currency billing and a local tax document whenever value and risk justify the route. In Brazil, a domestic tax invoice in reais changes reconciliation, audit, and, on Lucro Real, the PIS/COFINS credit conversation on the inbound invoice, with the review horizon already set in LC 214/2025.
2. Ban on personal cards for corporate SaaS, with a temporary exception of at most 30 days and reimbursement conditioned on inventory registration.
3. Remittance abroad only with prior tax classification when the direct route is chosen. In Brazil, whoever pays a remittance without an owner of the classification discovers at close IRRF, CIDE, PIS/COFINS-Importação, ISS, and IOF, depending on how the operation is qualified (SaaS/technical service under the standard RFB reading). Outside Brazil, the policy requires the local team to declare applicable digital taxes and withholdings with support from country counsel; detailed regulatory analysis outside the Brazilian corpus is marked preliminary until local validation.

The policy does not need to be a tax manual. It needs to stop the sentence “we’ll sort the invoice later.”

Step 7: Choose the contracting route by criteria, not habit

The route (direct import, local intermediary, regional channel) is a policy decision with explicit trade-offs. The habit of “always buy on the vendor’s site” is not a criterion.

Compare routes at the approval table with the same columns:

The full channel comparison is in direct purchase or software marketplace. In the policy, the point is the trigger: above a TCO ceiling, or when a domestic invoice is required, the local route becomes default and the direct route becomes a justified exception.

When the policy prioritizes predictable local contracting, Nexforce Marketplace enters as the buyer’s path: international software and AI priced in local currency, tax invoice, centralized management, FX lock, and regional methods (PIX, boleto, installments). The public ConectCar case, a company in the Itaú group, records roughly 10% reduction in international software costs on that route (ConectCar case). The policy cites the path by attributes (invoice, currency, centralization), never by the margin of whoever intermediates.

Step 8: Close renewal, expansion, and offboarding

Renewal is where a SaaS procurement policy proves it is a living document rather than an onboarding PDF. Offboarding is where shadow IT returns with a former employee’s login.

Include in the rulebook:

1. Renewal calendar with alerts at 90, 60, and 30 days for contracts above tier B.
2. Real-usage review (active seats vs contracted, features turned on vs paid) before any auto-renew.
3. Expansion rule: seats and add-ons above X% of base contract reopen the tier flow, even inside the term.
4. Two-sided offboarding: HR or the manager removes access in the IdP; procurement confirms cancellation or ownership transfer at the vendor and archives evidence.
5. Ban on renewal on a natural person’s card with no exception.

Companies that control only the first purchase and ignore renewal pay full price in year two with less scrutiny than in year one. The policy reverses that: renewal has the same rigor as the first buy, with a shorter cycle because the dossier already exists.

How do you verify that the SaaS procurement policy is working?

Verification uses four operational evidence points a controller can read without creative interpretation: complete inventory, rate of out-of-flow requests, average approval time by tier band, and share of renewals with revised TCO. If the document exists and a personal card still pays a critical tool, the policy did not operate.

Numbers, not narrative.

Run the checklist below 60 days after publication and every quarter:

1. Inventory coverage. Target: 100% of tools with corporate login listed with owner, value, and renewal date.
2. Out-of-flow requests. Declining target. Each exception becomes a record with reason and correction plan, not silence.
3. Tier SLA. Share of requests decided inside the band’s deadline. A slow tier pushes shadow IT.
4. Renewal with dossier. Contracts above tier B renewed with updated TCO and revalidated security checklist.
5. Sampled offboarding. Monthly draw of departures: SaaS access removed within 24 hours in the IdP and at the vendor.

The expected result is dull and healthy: fewer surprises at close, fewer duplicate tools, fewer auto-renewals of a product nobody has opened in four months. When governance already exists and the next cost cut comes from contracting route and consolidated portfolio, not from another round of shadow-IT scolding, the natural path is reducing international software costs.

Which common mistakes destroy a SaaS procurement policy?

The mistakes that most often destroy a SaaS procurement policy reopen, one by one, the hole the document promised to close: vague scope, tier without a deadline, optional TCO at the approval table, security after go-live, tolerated personal cards, and renewal on autopilot. Any one of them is enough to send purchasing back to the team chat.

1. A 40-page policy nobody reads. Prefer ten operable pages and checklist annexes. A rulebook that does not fit the ticket flow does not exist.
2. Approval by diffuse consensus. Without RACI, everyone comments and nobody decides.

The requester reads silence as yes. That is the shortest path between a ticket comment and a signature without TCO.

1. Permanent exception for the “founder’s tool.” An exception without a deadline and without an owner becomes a second regime. The policy either binds the C-level or becomes theater.
2. TCO only on the board slide. If tier B approves on list price, leadership inherits the full bill.
3. Security as opinion. A binary checklist beats “I think it’s fine.” Opinion does not audit.
4. Ignoring currency and invoice. Team happy with the trial; finance unhappy with reconciliation and missing tax documentation.
5. Shadow IT treated only with scolding. Scolding without an easy path to regularize pushes the tool to personal email. Offer a fast-track regularization path with limited amnesty in the first cycle.

Stage, evidence, and approver table

The table below is the operational heart of a SaaS procurement policy: each request stage requires minimum evidence and a named approver, so the intake form and the internal wiki speak the same language. Paste both in the same place and train the team once.

Paste into the wiki. Use on intake.

Without evidence at the stage, the request does not climb the tier. That single rule prevents most improvised exceptions leadership only discovers at quarterly close, when SaaS spend is already contracted and offboarding of the old vendor has not even started.

FAQ

Before closing the rulebook, procurement and finance repeat the same questions: document owner, trials, PIS/COFINS credit, CIDE on the direct route, review cadence, and SaaS already bought outside the flow. The answers below belong in the internal FAQ of the SaaS procurement policy and keep the debate from reopening on every request.

Who should own the SaaS procurement policy?

The owner is a role with a written mandate to publish and revise: CFO, head of procurement, or controller. Committees review. They do not publish.

Without a named owner, the policy ages in silence and shadow IT returns through the corporate card of whoever is in a hurry and will not wait for tier B.

Does the policy need to cover trials and free tools?

Yes, when there is a card, automatic conversion, personal data, or customer data. Billing becomes a purchase. A trial without a card and without sensitive data may use simplified inventory registration, provided the team owner declares the end date and what happens if nobody cancels before automatic conversion. The border stays written in scope.

Does Lucro Presumido benefit from PIS/COFINS credit on SaaS purchases?

No. Lucro Presumido does not credit PIS/COFINS on inbound invoices. The operational benefit of a route with a domestic invoice for that regime is local currency, documentation in reais, FX lock, and less reconciliation friction. The 9.25% credit is a Lucro Real conversation under the non-cumulative regime, anchored on the domestic invoice of the local path. That cut holds in 2026; under LC 214/2025, PIS/COFINS (including Import) expire in 2027 with CBS, and the policy must schedule a review of the credit criterion when the consumption-tax regime migrates.

Does CIDE apply to foreign SaaS purchases?

In Brazil, the 10% CIDE applies to SaaS and technical services under the Federal Revenue reading (SC Cosit 191/2017 and Law 10.168/2000). The §1°-A exemption of art. 2 of Law 10.168/2000 applies exclusively to pure software licenses without technology transfer, a category distinct from SaaS. The procurement policy treats that line in direct-route TCO; it does not assume exemption by default.

How often should the policy be reviewed?

Formal review at least once a year and whenever the tax regime, approval org chart, or annual software spend ceiling changes. Point reviews fit when a security incident or a fine exposes a hole in the flow, and also when the LC 214/2025 calendar changes the credit criterion the policy promises in TCO.

What should be done with SaaS already contracted outside the policy?

Limited amnesty in the first cycle: 60 to 90 days to register in inventory, complete the checklist, and fit the renewal tier. After the window, a tool outside the rulebook loses reimbursement and access through the corporate IdP. Without consequence, there is no regularization.

References and further reading

• ABES/IDC, Brazilian Software Market: Overview and Trends
• Law 10.168/2000 (CIDE), Planalto
• Complementary Law 214/2025 (consumption tax reform), Planalto
• How to calculate the total cost of foreign SaaS
• Direct purchase or software marketplace
• Reduce international software costs
• ConectCar case: reducing international software costs
• Nexforce Marketplace

What is the next step after publishing the policy?

The next step is to run the first full cycle: publish the rulebook, migrate the inventory in 30 days, run the intake form on every new request, and measure the four verification evidence points on day 60. Without a measured cycle, the SaaS procurement policy remains a text of good intentions.

Companies that already feel a dollar invoice double on the way to finance gain speed when the default route favors local currency and a domestic tax invoice. Nexforce Marketplace exists for that buyer: it centralizes international software and AI with billing in reais, tax invoice, FX lock, and local methods, while the internal policy defines who requests, who approves, and what happens at renewal. Governance belongs to the company. The predictable route is a criterion choice, not improvisation on a card.