ERP & WhatsApp Integration for UK Businesses: Architecture, Costs, and Common Pitfalls
Payment reminders, VAT invoices, and order confirmations sent directly from your ERP to customer WhatsApp: the scalable architecture and true costs for UK firms.
by Cleverson Gouvêa

Integrating ERP with WhatsApp is the most frequent request I hear from businesses that are already generating good revenue but still manually copy invoice details from their system and paste them into a mobile phone for customers. The ERP knows an invoice is due. WhatsApp is where the customer responds. Between the two, a finance team member performs the work of a webhook. This guide shows the architecture that works, the true costs following the price changes in October 2026, and the pitfalls I've seen derail projects.
TL;DR
- The secure path to integrating ERP with WhatsApp is the official API (Meta Cloud API) with your own intermediate layer: a queue, an event database, and error handling. Connecting the ERP directly to Meta works in demonstrations but breaks down in the first week of volume.
- Since 1st October 2026, Meta also charges for customer service messages within the 24-hour window, at the same rate as utility messages. Based on the BRL rates in effect from July 2026, utility messages cost R$0.035 per message and marketing messages R$0.3217.
- The biggest cost is rarely Meta. It's the development of the bridge, hosting, and maintenance when the ERP API or Meta's API changes versions.
- Do not proceed with the integration if your volume is only a few dozen messages per day or if your phone number database in the ERP is inaccurate. Fix the data first.
Why integrating ERP with WhatsApp became a priority in 2026
UK customers respond on WhatsApp. Debt collection emails often go to spam, SMS messages can look like scams, and calls frequently go unanswered. The maths is simple: if the message that generates cash flow (invoice, payment link, VAT invoice, tracking information) is sent via the channel where the customer is, it gets read.
What changed in 2026 wasn't the demand. It was the cost of doing it wrong. Three Meta movements impacted projects for those looking to integrate ERP with WhatsApp this year:
- Local Currency Billing. From 1st July 2026, businesses with revenue in Brazil could create WhatsApp Business Accounts (WABA) billed in BRL, with invoices issued by Facebook Brazil. The migration of all accounts to BRL was mandatory by 30th June 2027; from 1st July 2027, Meta ceased delivering messages from accounts that had not migrated (official pricing documentation).
- End of Free Replies. Since 1st October 2026, customer service messages (free-form text) and utility templates sent within the 24-hour window became chargeable, at the same price as the utility category in each market (Meta's page on non-template messages).
- Portfolio-wide Limits. From 7th October 2025, the limit on business-initiated messages applied to the entire portfolio, not to each number individually.
I detailed the full calendar in WhatsApp API changes from 2026 to 2028. Here, the focus is different: how to design the integration so these changes don't become a crisis.
The right architecture for integrating ERP with WhatsApp
In over 15 years of building integrations (Moodle with academic systems, e-commerce stores with payment gateways, ERPs with CRMs), I've learned that the design that survives always has the same format: the ERP never communicates directly with Meta. Between the two, there's a service of your own, which I call middleware (intermediate layer).
The four components
- ERP Connector. Reads events from the ERP (invoice issued, order fulfilled, invoice due) via webhook, if the ERP offers it, or via periodic query (polling), if it doesn't.
- Message Queue. Each send becomes an item in a queue (Redis, RabbitMQ, or a well-indexed database table). The queue absorbs peaks and allows resending without duplication.
- Cloud API Client. Sends approved templates, stores the ID returned by Meta, and handles error codes.
- Webhook Receiver. Receives status updates from Meta (sent, delivered, read, failed) and customer responses, and writes them back to the ERP when appropriate.
Why not connect the ERP directly to Meta
Because both sides have traffic rules that don't match. The Cloud API accepts, by default, 80 messages per second per number. The ERP usually accepts far less. For instance, the Omie API limits calls to 240 per minute for each IP, App Key, and method combination, accepts a maximum of 4 simultaneous requests, and blocks access for 30 minutes after the 10th error request (Omie API consumption limits). If each message read on WhatsApp triggers an uncontrolled query to the ERP, you'll block your own integration during a morning of payment reminders.
The middleware is where you apply the brakes: batch processing, caching, and exponential backoff between retries. Those who try to integrate ERP with WhatsApp without this layer discover the ERP's limits in production, not during testing.
Typical payment reminder flow
- The ERP marks the invoice as "due in 3 days".
- The connector reads the event and records it in the queue: customer, amount, invoice link or payment details.
- The Cloud API client sends the approved utility template.
- Meta returns the status via webhook; the middleware records "delivered" and "read".
- If the customer replies "I've paid", the conversation goes to a customer service agent, with the invoice history alongside.
- When the ERP registers the payment, the middleware ends that customer's reminder sequence.
Official or unofficial API: the choice that defines the project
Many businesses looking to integrate ERP with WhatsApp start with a library that emulates WhatsApp Web because it doesn't charge per message. I've worked with clients who came to us after losing their main number in a block, with their entire contact list inside.
| Criterion | Official API (Cloud API) | Unofficial Solution (Emulated WhatsApp Web) |
|---|---|---|
| Cost per message | Yes, per delivered message | No |
| Risk of number blocking | Low, if policies are followed | High, violates terms of service |
| Status and reply webhooks | Native, with resend for up to 7 days | Depends on the library |
| Templates for initiating conversations | Mandatory and Meta-approved | Do not exist (and this is why it gets blocked) |
| Scale | 80 msg/s by default, up to 1,000 msg/s | Limited to one mobile session |
| Contract and invoice | Meta or official provider | None |
For an ERP, which sends business-initiated messages daily, the unofficial option is a gamble against the house. I compared the two models in detail in WhatsApp Business app vs official API.
How much it costs to integrate ERP with WhatsApp: the three accounts
The budget for integrating ERP with WhatsApp has three lines. Almost everyone only looks at the first.
1. Messages (Meta)
Since July 2025, Meta charges per delivered template message, with prices by category and recipient country. Based on the BRL pricing table that became effective on 1st July 2026, the rates for Brazil were:
| Category | Typical ERP Use | Price per message (BRL, Jul/2026) |
|---|---|---|
| Utility | Invoice, VAT invoice, order confirmation, tracking | R$0.035 |
| Authentication | Access code for customer portal | R$0.035 |
| Marketing | Promotion, re-engagement, offer | R$0.3217 |
| Service (free-form text in 24h window) | Finance team's reply to customer | Same as utility rate, from 01/10/2026 |
Meta only changes prices on the first day of each quarter, and utility and authentication categories have volume discounts, aggregated across the portfolio. Always check the BRL pricing file on the official page before finalising your estimate. For a deeper dive into this part, see cost per conversation on the official WhatsApp API.
Payment reminder sequence example: 2,000 invoices per month, with a notice 3 days before and on the due date, totals 4,000 utility templates. At R$0.035 each, this totals R$140 per month. If 15% of customers respond and the finance team exchanges 4 messages with each, that's an additional 1,200 service messages, or R$42. This channel costs less than an hour of a junior staff member's time.
Those looking to integrate ERP with WhatsApp also need to pay attention to the category. A common pitfall: a utility template that includes "take advantage and discover our new line" is reclassified as marketing, and the price increases almost tenfold. Write your payment reminder sequences to be concise and transactional.
2. Development
This is where the bulk of the cost lies. The items that determine the project size:
- Quality of the ERP API. Bling, Omie, and Tiny have documented REST APIs. Protheus and SAP Business One often require a custom layer or direct database access. A custom-built ERP without an API requires creating the API first.
- Number of workflows. Just payment reminders is one project. Payment reminders, orders, tracking, NPS, and customer service with ERP feedback is another.
- Writing back to the ERP. Simply reading is straightforward. Recording customer responses, settling invoices, or opening support tickets requires business logic and testing.
At Agathas Web, custom development begins precisely with this assessment, before any timeline estimates.
3. Hosting and Maintenance
The middleware needs to be online 24 hours a day, with a valid HTTPS certificate, to receive webhooks. Meta attempts to resend a failed webhook for up to 7 days and warns that this can generate duplicate notifications. Payloads can reach 3 MB (Meta webhook overview). Factor in server costs, monitoring, event database backups, and the hours required to keep up with Graph API and ERP version changes.
When integrating ERP with WhatsApp is not worthwhile
I'm the first to say no when a project doesn't pay for itself. Integrating ERP with WhatsApp isn't an obligation for every business. Avoid (or postpone) if:
- Volume is low. With 30 invoices per month, a customer service agent using WhatsApp Business with quick replies can manage. The integration won't pay for itself.
- Your database is inaccurate. Landline numbers in the mobile field, numbers without area codes, customers with three different contacts. Integration doesn't clean data; it spreads errors at scale. Clean up your data first.
- No opt-in exists. Meta's policies require consent for business-initiated messages, and UK GDPR and the Data Protection Act 2018 require a legal basis for processing. If the customer has never authorised contact via WhatsApp, start collecting this during registration and at checkout.
- The ERP will be replaced in six months. Wait for the migration. Integrating with a system that's about to be decommissioned means paying twice.
- The goal is mass promotional messaging. Marketing at R$0.3217 per message, with daily portfolio limits and a risk of declining number quality, calls for a different strategy, not an ERP integration.
The pitfalls that most commonly derail integrations
Duplicate messages
This is the number one problem for those who have just integrated ERP with WhatsApp without idempotence. Resent webhooks, reprocessed queues, operators clicking twice. The customer receives the same invoice three times and complains. The defence is idempotence: each send has a unique key (invoice ID + reminder stage), and the middleware rejects the second attempt. On the webhook side, record the ID of each event and ignore duplicates.
Slow webhook response
If the receiver processes everything before responding, Meta interprets it as a failure and resends. Respond with HTTP 200 immediately, record the event, and process it later in a queue.
Phone number as customer key
This is the new pitfall for 2026. With WhatsApp usernames, contact may arrive identified by a BSUID (Business-Scoped User ID), not by phone number. Integrations that match customers solely by phone number will create duplicate records. I explained the impact in WhatsApp usernames and BSUID.
Message limits and quality
The limit counts unique customers reached outside the 24-hour service window, in tiers of 250, 2,000, 10,000, 100,000, and unlimited. It increases automatically when quality is good and you've used at least half of the limit in the last 7 days. A poorly written reminder sequence that generates blocks and reports will degrade quality and halt scaling.
Expiring tokens and versions
User tokens expire; use system user tokens. Each Graph API version has an end-of-life date. An integration without a technical owner stops working on a Monday without warning.
Checklist for securely integrating ERP with WhatsApp
Before signing any quote, check:
- Verified Account. Business Portfolio verified with Meta and a dedicated API number (the same number cannot run on both the regular app and the API simultaneously).
- Payment method registered and a plan to migrate the WABA to BRL by June 2027 (if applicable to your market).
- Approved templates for each stage, in the correct category.
- ERP event map: which events exist, whether there's a webhook or only polling, what are the API limits.
- Opt-in recorded with date and source, per customer.
- Idempotence and queue in the design, not as a "future improvement".
- Monitoring: alerts when the failure rate exceeds a limit, when the queue accumulates, or when webhooks stop arriving.
- Technical owner defined for tokens, versions, and price changes.
If three or more items are still open, the project isn't ready to start. It's ready for planning.
How Agathas Web solves this
We work with the official WhatsApp API in production, maintain Linux servers with managed hosting, and have been developing integrations since 2008, from Moodle platforms with academic systems to ERPs with payment gateways. When a client asks to integrate ERP with WhatsApp, the project follows four stages.
What's included
- 1 to 2-week diagnostic: review of your ERP's API, event mapping, volume and monthly cost calculation with Meta, and a frank recommendation (including "don't do it now," if applicable).
- Official account configuration: portfolio verification, number, templates, and BRL billing setup.
- Custom middleware: queue, idempotence, webhook receiver, status dashboard, and writing back to the ERP when the workflow requires.
- Hosting and monitoring on our managed infrastructure, with HTTPS, backup, and alerts.
- Continuous maintenance: we track Graph API version changes, pricing table updates, and ERP API changes.
How it works in practice
We start with the workflow that generates the most cash flow (almost always the payment reminder sequence), put it into production, and measure. Subsequent workflows are built on the same foundation. If your problem is customer service with multiple agents on the same number, and not integration, Voyia already solves it without custom code.
How to get started
Contact us via our systems development and integrations page, tell us which ERP you use and how many invoices or orders you process per month. We'll respond with the scope of the diagnostic and the next steps.
Conclusion: integrate what generates cash flow, in a way that scales
Integrating ERP with WhatsApp is worthwhile when the volume justifies it, the database is clean, and the customer has authorised contact. Meta made the rules more expensive and clearer in 2026: everything sent via the API has a price, and those who don't migrate to BRL by June 2027 will cease sending messages (for the Brazilian market). What separates a stable integration from a recurring problem is the intermediate layer: a queue, idempotence, well-handled webhooks, and someone monitoring the changes.
If you want to start with payment reminders and measure the return before expanding, contact the Agathas Web development team.
Related posts

Managed Hosting vs. VPS: Who's on Call When Your Website Fails?
Your website crashed at 2 AM. With a VPS, it's your problem; with managed hosting, it's a team's. See the real division of responsibility and cost for each.

Two-Factor Authentication for UK SMEs: Your Baseline Security
Leaked passwords are the most common entry point for cyberattacks. Discover which accounts to protect first, the best authentication factors, and the typical costs for UK businesses.

Safeguarding Your Web Server: WAF, fail2ban, and Rate Limiting Explained
94% of logins on Cloudflare's network are bots. Discover how WAF, rate limiting, and fail2ban can thwart attacks before they bring down your website.