Webhooks in ERP & Accounting: Models, Payloads and Native Support
- Dr. Themo Voswinckel ⎪Co-Founder
- 3 days ago
- 7 min read
Webhooks are often described as a “standard building block” of modern APIs. In practice, however - especially in ERP and accounting software - they are anything but standard.
This article explains what webhooks are and why they matter, outlines the two dominant webhook models used in ERP and accounting systems, examines why many vendors still do not offer webhooks at all, and provides an overview of which popular systems support native, manufacturer-provided webhooks today. This article lays the foundation for the second blog, where you’ll learn how Maesn enables Unified Webhooks across all systems.
Key Takeaways
Webhooks enable event-driven integrations, but many ERP and accounting systems still lack native support.
Two main models exist: App-based webhooks and User-based webhooks.
Where webhooks are missing, integrations often fall back to polling or expensive third-party tools.
Webhook payloads range from “ping and pull” signals to extensive data payloads.
Maesn Unified Webhooks standardize models, payloads, and formats for all systems - even for those, that do not offer native webhooks.
Webhooks Enable Event-Driven Integrations
A webhook is a mechanism that allows one system to actively notify another system when a specific event occurs. Instead of continuously querying an API to check whether data has changed, a webhook enables the source system to push a notification as soon as something relevant happens, such as an invoice being created, a payment being booked, or a customer record being updated.
Technically, a webhook is usually an HTTP POST request sent to a predefined URL. The request contains information about the event and, depending on the system, additional context or data. This approach allows integrations to react almost in real-time to changes while reducing unnecessary API traffic caused by polling.
For integration-heavy environments, webhooks are a key enabler of scalable and responsive architectures.
Legend
Tenant: Software vendor offering Integration
User: Customer of the software vendor
App: Integration "app" provided by the tenant
Why Webhooks Are Especially Valuable in ERP and Accounting
ERP and accounting systems are often the system of record for critical business data. Changes in these systems usually have downstream effects on reporting, payments, CRM systems, or operational workflows. Without webhooks, integrations often rely on scheduled polling jobs that introduce delays, increase API load, and complicate error handling.
Webhooks help mitigate these issues by enabling near real-time updates and clearer event semantics. They make it easier to build automation, reduce synchronization latency, and keep distributed systems consistent. In theory, this makes webhooks an ideal fit for ERP and accounting integrations.
In practice, however, their adoption in this domain has been slow.
The Two Dominant Webhook Models Used by ERP Vendors
Across ERP and accounting platforms, two different webhook models have emerged. Understanding these models is essential for designing reliable integrations - in case you are not using Maesn.
App-based Webhooks as a Centralized Event Entry Point
In an app-based webhook model, a software vendor allows a single webhook endpoint to be configured for an entire application or integration. All events from all connected users are sent to this one endpoint. Each webhook payload includes a user identifier, so the receiving app can determine which user the event belongs to.
This approach is common in accounting platforms with strong app marketplaces, such as QuickBooks Online and Xero. From the vendor’s perspective, this model simplifies management and scales well across thousands of small tenants. From the tenants’s perspective, it requires robust internal routing, security validation, and user isolation.
User-based Webhooks with Explicit Subscriptions
In a user-based webhook model, webhook subscriptions are created per user. Each subscription explicitly defines which events should be delivered and where they should be sent.
This model is more common in ERP and mid-market systems, where data isolation, permissions, and compliance requirements are stricter. Systems such as Microsoft Dynamics 365 Business Central or weclapp follow this approach. While more complex to manage, user-based webhooks offer finer control and clearer boundaries between user environments.
Maesn Unified Webhooks enables the secure and enterprise-ready user-level webhooks for all ERP and Accounting systems. More informations read the second Blog.
How Webhook Payloads Differ Between Systems
Webhook implementations also differ significantly in the amount of data they deliver. Some systems use a so-called “ping and pull” approach, where the webhook only signals that something has changed and includes user and object identifiers. The receiving system must then fetch the full data via the API in a second step. This pattern is common in enterprise-oriented ERPs and helps keep payloads small and secure.
Other systems include meaningful business data directly in the webhook payload. This can reduce the number of follow-up API calls and simplify processing, but it also increases payload size and places more responsibility on the sender.
In our experience, even more extensive payloads often still miss information required for real-world use cases, which means a second API call is usually necessary anyway. Maesn Unified Webhooks standardize webhook payloads across all systems by consistently following the “ping and pull” principle to ensure the highest security standards. Read more about this approach in the second blog.
Native Webhook Support Across Popular Systems
The following overview shows which systems provide native, manufacturer-supported outbound webhooks and how they are implemented. Systems without official webhook support are explicitly marked as offering no webhooks.
System | Native Webhooks | Webhook Model | Payload Style | Webhook with Maesn |
Abacus | No webhooks 🚫 | – | – | Yes ✅ |
Bexio | No webhooks 🚫 | – | – | Yes ✅ |
BuchhaltungsButler | No webhooks 🚫 | – | – | Yes ✅ |
DATEV Rechnungswesen | No webhooks 🚫 | – | – | Yes ✅ |
DATEV Unternehmen Online | No webhooks 🚫 | – | – | Yes ✅ |
Yes ✅ | User-based | Ping → Pull | Yes ✅ | |
Websockets ⚠️ | – | – | Yes ✅ | |
FreeAgent | No webhooks 🚫 | – | – | Yes ✅ |
Yes ✅ | User-based | Event payload | Yes ✅ | |
Holded | No webhooks 🚫 | – | – | Yes ✅ |
Yes ✅ | User-based | Event payload | Yes ✅ | |
Yes ✅ | User-based | Ping → Pull | Yes ✅ | |
Yes ✅ | User-based | Event payload | Yes ✅ | |
Odoo | No (outgoing) webhooks 🚫 | – | – | Yes ✅ |
Pennylane | No webhooks 🚫 | – | – | Yes ✅ |
Yes ✅ | User-based | Event payload | Yes ✅ | |
Yes ✅ | App-based | Event payload | Yes ✅ | |
Sage Accounting | No webhooks 🚫 | – | – | Yes ✅ |
Sage Active | No webhooks 🚫 | – | – | Yes ✅ |
Sevdesk | No webhooks 🚫 | – | – | Yes ✅ |
Snelstart | No webhooks 🚫 | – | – | Yes ✅ |
Twinfield | No webhooks 🚫 | – | – | Yes ✅ |
Visma eAccounting | No webhooks 🚫 | – | – | Yes ✅ |
Yes ✅ | User-based | Event payload | Yes ✅ | |
Yes ✅ | User-based | Event payload | Yes ✅ | |
Beta⏳ | Xentral-specific | – | Yes ✅ | |
Yes ✅ | App-based | Ping → Pull | Yes ✅ |
Websockets vs. Webhooks in ERP and Accounting Systems
A few ERP and accounting systems, such as Fortnox, use websockets instead of webhooks to deliver change events. Websockets establish a persistent, bidirectional connection that streams events in real time, whereas webhooks rely on discrete HTTP requests sent when an event occurs. While Websockets can provide very low latency, they also introduce additional complexity: connections must be kept alive, reconnect logic must be handled carefully, and scaling becomes more challenging - especially across many users. Webhooks, by contrast, are stateless, easier to secure, and simpler to operate at scale. For this reason, webhooks are generally better suited for cross-system ERP and accounting integrations, while Websockets are often used in more controlled or vendor-specific scenarios.
Limited Object Coverage in Native Webhooks Leaves Critical Gaps
Even when ERP and accounting systems support native webhooks, they often cover only a limited set of objects. It is common to see webhooks for sales-related entities like invoices or sales orders, while important purchasing objects such as purchase orders are not supported.
This forces teams to combine webhooks and polling within the same integration.
Maesn Unified Webhooks address this by complementing native webhooks with synthetic webhooks. Unsupported objects are monitored via polling and emitted as unified webhook events, ensuring consistent coverage and behavior across all systems.
Unified User-Based Webhooks for All ERP and Accounting Systems with the Maesn Unified API
Webhooks in ERP and accounting are fragmented, inconsistent, and often missing entirely. Maesn tackles this complexity head-on with Unified Webhooks for all ERP:
User-based webhooks only
Synthetic webhooks for systems without or with limited native webhooks
All events follow the same unified, security-first ping-and-pull pattern
Consistent payload structure
The result is simple and powerful: all webhooks behave the same across all systems. This is unification the Maesn way - thought through end to end, built for security, scalability, and developer convenience. Designed by a product team, for product teams. More informations read the second Blog or in our Docs.
Why Many ERP and Accounting Systems Still Offer No Native Webhooks
Despite the clear advantages of event-driven integrations, many ERP and accounting systems still do not offer native, manufacturer-supported webhooks. This is often rooted in legacy architectures, a strong reliance on batch processing, and strict audit or compliance requirements that make real-time event delivery harder to implement and maintain. In addition, many products in this space were historically designed around manual workflows rather than continuous system-to-system automation.
When native webhooks are missing, polling is often perceived as the only viable alternative. While polling is technically straightforward, it introduces delays, increases API traffic, and makes integrations less efficient and less reactive.
Some ERP systems, such as Odoo, try to close this gap by offering third-party or add-on solutions at the user or tenant level that effectively simulate webhooks by polling the system internally and emitting events externally. These solutions can improve responsiveness, but they typically come with significant recurring costs - often exceeding 200 € per user per month - which makes them expensive at scale.
As a result, many teams fall back to direct polling despite its limitations. While not ideal, polling often remains the most pragmatic and cost-effective option in environments where native webhooks are unavailable and third-party alternatives are prohibitively expensive.
What This Landscape Means for Integration Teams
For teams building integrations across multiple ERP and accounting systems, the main challenge is not handling webhooks themselves. The real challenge lies in dealing with inconsistent webhook models, different payload strategies, and the frequent absence of any webhook support at all.
Successful integration strategies therefore need to abstract these differences, combine event-driven approaches with fallback mechanisms such as polling, and provide a unified way to consume changes across systems.
See how Maesn eliminates the complexity of ERP webhooks with Unified Webhooks in our second blog.
