A distribution company I worked with in Beirut spent fourteen weeks building an AI-driven demand forecasting layer on top of their ERP. The pilot beat every benchmark we set. Forecast error dropped into the low single digits, warehouse teams in three cities were already redrawing their reorder schedules around it, and the CEO had told his board the rollout was essentially done.
Then the vendor sent the first full invoice. It came in USD, priced by consumption, and it was 40 percent higher than the pilot month because usage had scaled the way it was supposed to. Finance froze the rollout the same week. Not because the model was wrong. Because nobody had answered, before the contract was signed, how a Lebanese company converts local revenue into a variable monthly dollar obligation without knowing in advance what that number will be.
I have now watched some version of this happen at four different companies across Lebanon and the wider region. The pattern is always the same. The technology works. The project stalls anyway, months after go-live, at the desk of a CFO or a procurement officer who was never in the room when the contract terms were negotiated.
The mismatch nobody names
Most applied-AI vendor contracts are built around three assumptions: pricing in a stable currency, banking rails that move money without friction, and a customer whose budget can flex month to month as usage grows. Those assumptions are reasonable in the markets where the pricing models were designed. They do not hold in Lebanon, and they hold only partially across much of the rest of MENA.
What replaces them here is currency volatility, capital-control and correspondent-banking friction on cross-border dollar transfers, and a budgeting culture built around fixed annual line items approved once and defended for twelve months. An AI vendor contract that ignores this gap isn't wrong on the technology. It's wrong on the arithmetic of how the client actually moves and plans money — and that gap is what kills the project, not the model.
Three friction points, named plainly
Currency and banking rails. Most AI vendors offer no local-currency billing option. Payment has to move as a dollar wire, which in Lebanon and several neighboring markets means transfer limits, correspondent-bank delays, and sometimes weeks of uncertainty about whether a payment will clear on time. A subscription that assumes same-day settlement is a subscription built for a different banking system than the one most regional companies actually operate inside.
Consumption pricing against a fixed annual budget. Usage-based billing has no ceiling by default. It is designed to scale with adoption, which is a feature everywhere except inside a finance function that approved one fixed number for the year and has no mechanism to flag a spike before the invoice arrives. The company I described above didn't lack the money. It lacked forty-five days of warning.
Procurement built for a different kind of purchase. Most regional procurement processes were designed for one-time software licenses — evaluate, approve, buy, done. An AI subscription is not that. It is a monthly relationship with a vendor who will change models, adjust pricing, and shift usage patterns over the life of the contract, and almost no procurement workflow I have seen in this region has a built-in cadence for reviewing any of that after signature.
Why the imported playbook misses it
Global AI vendors, analysts, and most AI consultants operate on a set of assumptions about banking and budgeting that simply are not true for a company moving money through a Lebanese, Egyptian, or Iraqi bank right now. Nobody in the sales process is incentivized to flag this. The vendor's job is to close the deal. The consultant's job, in most cases, is to validate the technology. The finance and banking mismatch sits in the gap between those two roles, and it is almost never raised until it is already a problem.
What to demand before you sign
None of this requires walking away from AI adoption. It requires negotiating the commercial terms with the same rigor applied to the technical evaluation. Before signing an applied-AI vendor contract in Lebanon or MENA, I ask clients to get clear, written answers to the following:
- Is there a local-currency or fixed-USD-equivalent billing option, or will every invoice be exposed to full exchange-rate movement between billing cycles?
- What is the confirmed banking rail for payment, and has the vendor's bank actually cleared a transfer from your bank before, or is this the first attempt?
- Is there a hard usage cap or an automated spend alert at a threshold you set, rather than discovering a spike on the invoice itself?
- Can the contract be structured as an annualized, committed spend rather than pure elastic consumption, so it maps onto a fixed-budget approval cycle instead of fighting it?
- Is there a quarterly contract review clause tied to actual usage data, so pricing and scope get revisited on a schedule rather than only when something breaks?
I also push clients to settle, internally, whether the AI line item is framed as opex or capex before the vendor conversation even starts. That framing decision changes which budget it competes against, who has authority to approve overages, and how much flexibility exists if usage grows faster than projected. Getting this wrong internally guarantees a fight with the vendor later, regardless of how good the contract terms are.
The strategic takeaway
The operators who get AI adoption right in this region are not the ones with the best model or the most polished pilot. They are the ones who treat their CFO as a co-author of the AI rollout plan from the first vendor call, not as a signature collected at the end. The technology stopped being the hard part of this a while ago. The money, the banking rails, and the budget structure are where these projects actually live or die — and that is a negotiation you have before the contract is signed, not a problem you manage after.
Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.
