WhatsApp INR Billing: The 31 December 2026 Deadline

From conversations to messages, and why that reset your maths

Meta’s developer pricing documentation states that effective 1 July 2025, it charges on a per-message basis, and that conversation-based pricing was replaced with per-message pricing on that date. Read that slowly. The billable unit moved.

Under the older model, a business paid for a conversation: a window of time opening when a qualifying message was delivered, inside which a certain amount of back-and-forth carried no additional charge. Planning was coarse but forgiving. You could estimate a campaign by counting how many people you expected to reach and roughly what proportion would reply, and the replies inside that window did not each carry their own line on the bill.

That forgiveness has gone. Under per-message billing the meter is the message itself, which means a campaign that generates high engagement now costs more than the same campaign with low engagement, and the old habit of estimating spend from audience size alone quietly stopped working somewhere around the middle of last year without most marketing teams sitting down to redo the arithmetic.

The practical effect on an Indian brand is a change in where the risk sits. Volume risk was the old one. Now there is a second risk sitting next to it, which is composition: what kind of messages you send, in what category, and how many of them a single customer journey actually consumes end to end.

We see this most sharply in real estate. A project launch broadcast that used to be forecast as one conversation per prospect now needs forecasting as a chain: the launch template, the follow-up, the site-visit reminder, the confirmation. Each has a category. Each has a rate.

The same reframing applies to hospitality and to D2C, where the messages sent after a booking or an order are the ones that actually build the relationship and are also the ones that now appear individually on an invoice. None of this makes WhatsApp worse. It makes an unexamined WhatsApp programme a more expensive one, and the gap between those two states is entirely a matter of whether somebody has sat down with the template library and the rate card in the same afternoon.

The four template categories, and why the choice now drives your bill

Meta’s documentation identifies four categories: marketing, utility, authentication and service. The category is not cosmetic. It determines whether a message is charged at all, and if it is, at what published rate.

Marketing templates are always charged, per Meta’s pricing page. That one is simple. These are your promotional sends: the launch announcement, the offer, the re-engagement nudge, the festive campaign, and if the intent is to persuade rather than to inform about something the customer already set in motion, it is marketing and it carries a cost every single time.

Utility templates behave differently. Meta’s page states that utility templates delivered within an open customer service window are not charged. That single line is where a lot of budget hides, because it means the same message can cost money or cost nothing depending entirely on whether the customer has recently written to you and the service window is open at the moment of delivery.

Authentication messages, per the same page, support volume-based rate reductions. Scale changes the unit. If you send one-time passcodes in any quantity, the effective cost per message is not flat, which matters to any D2C brand running login or checkout verification at volume across a large customer base. Service conversations became not-charged for all businesses effective 1 November 2024.

Here is our reading, marked as inference rather than something Meta states in these words. Category discipline is now a cost lever of the same order as audience discipline. Consider a brand sending its order updates as marketing templates because nobody ever checked the classification, paying full rate for messages that a correctly categorised and correctly timed utility send would not have been charged for at all. That gap compounds quietly. Every order, every month, until somebody reads the invoice properly.

Audit your template library. Category by category. It is dull work and it usually pays for itself inside a quarter.

What India billing localisation actually is

Meta’s pricing documentation states that India billing localisation launched on 1 January 2026 for partners and directly-integrated clients whose Sold-To country is India. Read that phrase again. Sold-To country is a billing attribute sitting on the account itself, not a description of where your customers happen to live, and the two come apart more often than you would expect in businesses that grew through acquisitions or agencies.

Localisation means the account bills in Indian rupees against an INR rate card, rather than billing in a foreign currency and leaving you to absorb the conversion. This is broadly a simplification. Your messaging cost stops moving because the rupee moved.

It also changes the invoice you reconcile against. That is finance work. A team that had built its monthly process around a dollar-denominated statement, a conversion rate and a variance line will find fewer moving parts once the account bills natively in rupees, but the transition itself has to be scheduled rather than discovered.

Hold on to one distinction. Localisation and migration are not the same event. Localisation is the capability Meta launched in January 2026, while migration is the action your own account has to take, and the window for taking that action closes on the last day of December 2026.

How to find out which currency your WABA is billed in

Most marketing teams do not know the answer to this. That is not carelessness. The billing currency of a WhatsApp Business Account is usually set once, at onboarding, by whoever did the onboarding, and then never surfaced again in any screen a marketer looks at.

Two places to look. Start in WhatsApp Manager, inside Meta Business Manager, and look at the billing or payment settings attached to the business portfolio rather than at the individual phone number. The currency is an attribute of the account and its payment method, so a portfolio can quite easily contain one WABA that has been localised and another that has not, particularly where numbers were added at different times by different teams or through different partners.

Then check the invoice. An actual PDF from the last billing cycle will tell you the currency in one glance, and it will also tell you whether the charges are being raised by Meta directly or passed through by your Business Solution Provider, which matters because the migration path differs.

If you buy WhatsApp through a BSP on a reseller arrangement, your BSP invoice may well be in rupees already while the underlying WABA is still billed to Meta in another currency. Those are separate facts. A rupee invoice from your vendor is not evidence that the account behind it has been migrated, and our advice is to ask the question in writing rather than infer it from what lands in your inbox.

Count your WABAs too. Enterprises with multiple brands, regions or business units routinely have more than they think, and Meta’s requirement is expressed across all WABAs in the business portfolio, not the busiest one.

What migration actually involves

Our reading, based on how the requirement is framed rather than on a step-by-step Meta guide, is that this is an account and billing action rather than a rebuild of your integration. Your templates do not need rewriting. Your webhooks do not change.

The work is mostly finance. A payment method denominated in rupees has to be attached to the account, tax registration details have to be correct on the business portfolio, and the entity named on the account has to match the entity that will be receiving the invoice, which is the point where a surprising number of migrations stall because the WABA was originally set up under an agency or a group holding company rather than the operating entity.

Sequence it in this order. Confirm the entity and tax details first, because they are the slowest to fix. Attach the rupee payment method second. Then migrate, then verify on the following billing cycle that the invoice actually arrived in rupees against an INR rate card.

Avoid the last fortnight of December. Finance teams in India are not lightly staffed in that window, they are closing a quarter, and a payment method that fails verification on 28 December leaves you three days.

If you run WhatsApp through a BSP, most of this is executed by them on your instruction. Your job changes. Make sure the instruction is given, dated and confirmed rather than quietly assumed.

What happens if you miss 31 December 2026

Meta is unusually direct here. It states that eligible customers must ensure all WABAs in their business portfolio are migrated to INR by 31 December 2026 to avoid disruptions, and that as of 1 January 2027 Meta will no longer deliver the messages of non-INR WABAs of eligible customers.

Messages stop being delivered. That is the stated consequence.

Picture the verticals we work in. What follows is illustration rather than anything Meta has described. A hospitality group whose booking confirmations, pre-arrival instructions and check-in details all travel over WhatsApp would lose its primary guest communication channel on the first morning of the new year, which happens to be one of the highest-occupancy days in the Indian hospitality calendar.

The pattern repeats. A D2C brand loses order and shipping updates, and the immediate second-order effect is a spike in support tickets from customers who no longer know where their parcel is. A real estate developer loses site-visit confirmations mid-campaign, with media already bought and running.

The recovery path is identical. It is the same migration you could have done calmly in October, executed instead under pressure while the channel is down. Our strong recommendation is to treat this as an operational continuity item owned by someone senior, not as a marketing housekeeping task, because the failure mode is a dark channel rather than a higher bill.

Who this actually applies to

Start with the short answer. Anyone running WhatsApp messaging through the WhatsApp Business Platform whose account falls in scope of the India localisation, which in practice means Indian businesses sending at scale through a BSP or through a direct integration.

If your marketing team schedules WhatsApp campaigns through a dashboard supplied by a vendor, you are on the Business Platform, and the WABA behind that dashboard belongs to you or is administered on your behalf. The dashboard hides the account. It does not remove your exposure to the account’s billing status.

The WhatsApp Business app, the ordinary one a small trader installs on a phone and uses by hand, is a different product and is not what this deadline addresses. One person, one handset, no exposure.

Where it gets genuinely messy is the middle case, which is common across Delhi NCR: a brand that started on the app, moved to a BSP two years ago for campaigns, and still has a legacy number sitting in a portfolio somewhere that nobody has audited since. Both sit in the portfolio. The requirement, as Meta words it, covers all of them.

What to ask your BSP this week

Send these as written questions, not as a phone call, because you want dated answers you can hold on to. Keep it short.

Start with the inventory. First, list every WABA associated with our business portfolio, including inactive numbers, and state the current billing currency of each one. Second, which of these have already been migrated to INR, and on what date. Third, for those not migrated, what exactly do you need from us, and what is your own internal cut-off for accepting migration instructions before 31 December 2026, because it will be earlier than Meta’s date.

Then two on commercials. Fourth, confirm in writing whether we are billed by you as a reseller or billed by Meta directly, since that determines who executes the change. Fifth, send us the current INR rate card by template category, and tell us the date it takes effect and how we will be notified when it changes.

Sixth, and this one gets skipped. Ask what your own per-message charges look like on top of Meta’s. Most BSPs add a platform fee or a markup per message, and under per-message billing that markup now scales with engagement rather than with conversation count, which may not be the commercial arrangement you agreed to when you signed.

One last signal. If a BSP cannot answer the first question inside two working days, that is information about the BSP.

Re-forecasting when the unit changes

The old forecast was audience multiplied by conversation cost. That formula is dead. It no longer describes what you will actually be charged, and rebuilding it is a genuinely useful exercise even setting the migration deadline aside entirely.

Build the new one bottom-up. Journeys, not campaigns. Take a single customer journey, write out every message that journey sends in sequence, and tag each one with its category and with whether it will land inside an open customer service window or outside one. That sequence, priced against your current rate card, is your unit cost per customer for that journey.

Multiply by expected volume. Repeat for each journey. Sum.

The number this produces is usually different from the old forecast in both directions. That surprises people. Journeys heavy in utility messaging that lands inside an open service window can come out cheaper than they did under conversation pricing, because those messages are not charged at all, while journeys that are mostly outbound marketing with long reply chains come out dearer because every leg of the chain now meters separately.

Then add a sensitivity. Model the same journeys at a higher engagement rate, say double the replies, and look at what happens to the total, because under per-message billing a successful campaign is a more expensive campaign and your finance team should learn that from a spreadsheet in July rather than from an invoice in February.

One more line. The rate card is denominated per category and per market, so a migration to INR is also the right moment to check whether the category mix you designed under the old model is still the cheapest way to say what you need to say.

Why we are not quoting you a per-message rate

You will find specific rupee figures for WhatsApp per-message pricing in a lot of places. Blog posts, comparison pages, agency decks. We looked for those figures on a Meta-published source and did not find them there.

Check the source itself. Meta’s developer pricing documentation, which is the page carrying the migration deadline, does not publish per-message rates in its body. It references rate cards in multiple currencies as being available on the WhatsApp Business website rather than printing the numbers on the documentation page.

So we will not repeat them. Rates are published per category and per market, they change, and a figure that was accurate for marketing templates in one market in one quarter is a liability if a reader budgets against it two quarters later without checking. Take your rates from Meta’s current rate card, or from the schedule attached to your BSP contract, and treat any rupee figure you read in an article, including a well-meaning one, as something to verify rather than something to plan with.

This is not us being coy. It is the difference between a page that is useful in December and a page that is wrong by then.