The integration risk sits in a document nobody at the table has read.
A mid-market operator decides to commission an AI system for one workflow. The workflow is well chosen, the numbers behind it are defensible, and the people who would use it want it. Then the build runs long, or lands smaller than the demo, or ships as a report that arrives every morning instead of the live queue everyone pictured. When that happens, the cause is very rarely the model. It is almost always that the system of record would not give up what the workflow needed, at the volume the workflow needed, on the terms the operator had assumed.
Those terms are published. Not by the AI vendor, and not in the statement of work, but by the company that sold you the ERP or the line-of-business system, in developer documentation and lifecycle pages that are free to read and that essentially no buyer reads before signing. We spent this week reading them for four products a mid-market operator plausibly runs. The four are not equally forthcoming, and the differences between them are the whole argument of this piece: one publishes exact numbers, one publishes the mechanics and prices the ceiling privately, one keeps the answer behind a login, and one publishes a date after which the question stops mattering.
Reading those documents takes an afternoon. Discovering their contents in month two of a build costs considerably more, and the cost lands as scope rather than as an invoice, which is why it is rarely attributed correctly afterwards. This is the single largest source of avoidable surprise in a mid-market AI engagement, and it is upstream of everything in data readiness, which asks whether the information is good enough, and upstream of how long a build takes, which assumes you can reach the information at all.
Four questions, asked in this order, before anyone quotes the work.
The order matters, because each question is only worth asking if the one before it came back the right way.
Is there a documented interface. Not whether the vendor says the product is open, and not whether a partner has built a connector. Whether there is published documentation describing how software talks to the system, which a developer who does not work for the vendor can read without a contract.
Does it expose the records this workflow needs. A documented interface that covers customers and invoices is not much help to a workflow about job routing. This is the question that fails most often and fails quietly, because everyone assumes an interface that exists covers everything the screen covers, and it frequently does not.
What is the ceiling, and who prices it. Every hosted system limits how much an outside application may ask of it. Sometimes the number is published. Sometimes the number is a function of what you pay, and the price of raising it is not on the page. Either way it is a real constraint on the design, and it is better known before the design exists.
How long does this system have. An integration is an asset with a useful life, and its useful life is bounded by the platform underneath it. If the system you are integrating with has a published retirement date inside your planning horizon, the integration is a bridge rather than a foundation, and it should be scoped and priced as one.
What four vendors actually publish, read this week.
Everything below was fetched and read on 25 August 2026 from the vendors' own documentation. Where a figure is quoted it comes from the vendor's page, not from a summary of it. Where we could not read the primary source, we say so rather than filling the gap.
Microsoft Dynamics 365 Business Central publishes the number.
This is the most generous of the four, and it is a useful baseline precisely because nothing is left to the imagination. Microsoft's operational limits page for Business Central online states that a production environment allows 600 OData V4 requests per minute, that at most 5 requests are processed concurrently, that at most 100 requests may be in flight including those waiting, and that the waiting queue holds 95. Cross any of those and the service returns HTTP 429. A request that sits in the queue for more than 8 minutes returns HTTP 503 instead. A single request may return at most 20,000 entities before the service returns HTTP 413, a batch may carry at most 100 operations, and an environment may hold at most 200 webhook subscriptions. Microsoft's separate rate limits page adds that a request has 10 minutes to complete, after which the service abandons it and returns HTTP 504. The newer per-user model raises the throughput allowance to 6,000 requests inside a five-minute sliding window while keeping the same five concurrent requests.
Read that as a design brief rather than as fine print. Five concurrent requests is the number that shapes an integration, more than the 600 per minute does, because it means an AI layer cannot fan out across a large set of records in parallel and expect the system to keep up. It has to work in a queue, with backoff, and it has to be built that way from the start rather than retrofitted when the first 429 arrives in production. The 200 webhook subscriptions matter for a different reason: they are the mechanism that lets you stop polling, and there are enough of them that a well designed integration should never need to poll at all.
Sage Intacct publishes the mechanics and prices the ceiling privately.
Sage documents the behaviour carefully and declines to publish a single headline figure, and the reason it declines is stated plainly, which is more honest than it first appears. The developer documentation says that concurrent connections to the gateway are limited by tenant, and offers an example: with 100 concurrent requests, five might be processed while the other 95 are held for approximately five seconds or until the requests ahead of them finish. The error handling page attributes an HTTP 429 to the client having hit the rate limit assigned to its contracted level of service, which is the sentence that tells you the ceiling is a commercial term rather than a technical one.
The developer FAQ is where it becomes concrete. Under the standard level of service, a company is allowed one API transaction job and one offline report job running at the same time. A third simultaneous request is held for 30 seconds, and if no slot opens in that window the request fails with a message saying there are too many operations running for this company. Sage's stated remedy is to upgrade the level of service package and to contact your account manager for details. No price for that upgrade appears anywhere on the page.
An operator scoping an AI workflow on Intacct should read that as a specific and answerable question to put to their account manager before the build is scoped: what level of service are we on, what does the next one cost, and what do our existing integrations already consume. It is the same shape of question as the one in the real cost of off-the-shelf AI at scale, where the meter belongs to somebody else and the bill grows with your success. Our own Sage Intacct integration playbook covers which workflows are worth putting through that meter in the first place.
Acumatica keeps the answer behind a login.
Acumatica's help site has a page describing the number of concurrent Web Services API requests permitted, which is exactly the document an operator would want before scoping a build. Requested on 25 August 2026, that page returned an HTTP 301 redirect to an access gateway, and the response carried an X-Robots-Tag: noindex header. We did not read it, and so we are not going to tell you what it says. Third-party summaries of these limits circulate and quote small figures for concurrent sessions, and we are not repeating them, because a number nobody at this end verified is worth less than an honest gap.
The practical consequence is the same either way, and it is not really a criticism of Acumatica. If the ceiling that governs your integration is in a document you can only reach as a customer, then the way to get it is to ask your reseller for it in writing, as a number, alongside what your current integrations consume. Any competent partner will produce it. The failure mode to avoid is treating the absence of a public figure as the absence of a limit, which is how a design gets built on an assumption that was never tested.
Microsoft Dynamics GP publishes a date instead.
There is a fourth category, and it is the one operators find hardest to hear, because the system in question usually works fine. Microsoft's lifecycle documentation states that support for Dynamics GP ends on 31 December 2029 for product enhancements, regulatory tax updates and technical support, that this date replaced a previously announced end date of 30 September 2029, and that security updates and patches will be made available, if needed, until 30 April 2031. The Microsoft Lifecycle listing shows a retirement date of 1 January 2030. Microsoft states that it is encouraging customers to move to Dynamics 365 Business Central.
The older versions are already gone. Extended support for Dynamics GP 2013 ended in April 2023, for GP 2015 in April 2025, and for GP 2016 on 14 July 2026, which is six weeks before this was written. GP 2018 and 2018 R2 hold extended support until 11 January 2028. An operator running GP 2016 today is running a system of record whose vendor support has fully lapsed, and Microsoft's own guidance to customers still on Dynamics GP is to talk to their reselling partner and to plan a move to Business Central.
That does not mean an AI build is impossible on GP. It means the integration has a known expiry, and the correct response is to say so out loud in the scope. A read-only layer that produces a report has a short enough payback to be worth building against a system with four years left. A deeply coupled bidirectional integration does not, and would be paid for twice.
The four ways in, and what each one costs you a year later.
Whatever the vendor publishes, there are only four routes from an AI layer into a system of record, and the order below is the order of preference in almost every case.
The documented interface. Read and write through the endpoints the vendor supports and documents. It is the cleanest option, it survives upgrades because the vendor has committed to it, and it is the only route where a rate limit is a published constraint rather than a surprise. Prefer it even when it exposes less than you want, and change the workflow to fit what it exposes before abandoning it for something less durable.
Events and webhooks. Subscribe to changes and react to them rather than asking repeatedly whether anything changed. It costs almost nothing against a rate ceiling, it is closer to real time than any polling schedule, and it exists only where the vendor has built it. Where it exists, use it. Business Central allows 200 subscriptions per environment, which is more than a mid-market integration is likely to need.
The database underneath. Read directly from the tables where the interface does not expose what the workflow needs. This works where you host the system yourself, and it carries a specific and underrated fragility: the schema is an internal detail the vendor may change in any release, so a routine upgrade can break the integration with nobody at fault and nobody obliged to fix it. Reserve it for reads, never for writes, and only with the operator's explicit agreement that the maintenance risk is understood.
Files and screens. A scheduled export into a folder is slow, one-directional and genuinely adequate for a workflow that reads history. Screen-level automation, where software drives the interface a person would otherwise use, belongs at the very bottom of the list. It breaks when the vendor moves a button, it is difficult to make auditable, and it should be sold and bought as a temporary bridge rather than as an architecture. It is not an argument against ever doing it. It is an argument for putting an end date on it in the same document that authorises it.
Polling or events is the decision the ceiling makes for you.
Most integration designs come down to one choice, and operators are rarely shown it. An AI layer that needs current information can ask the system repeatedly whether anything has changed, or it can be told when something changes. Polling is simpler to build, works against any interface, and consumes the rate ceiling continuously whether or not anything happened. Events consume close to nothing, but they exist only if the vendor publishes them, and they need somewhere to arrive.
Both vendors give the same advice in their own documentation. Microsoft tells integrators to use webhooks so that changes are pushed rather than pulled, and to batch and filter requests so that fewer are needed. Sage names frequent polling as a cause of rate-limit failures and tells integrators to consult Sage for a better way to be alerted to data changes. That advice is usually read as performance guidance. It is better read as pricing guidance, because on a system where the ceiling is tied to what you pay, a polling design quietly turns an engineering choice into a recurring line item.
Where the ceiling is low and events do not exist, the workflow itself has to change. A queue that everyone imagined updating live becomes a batch that refreshes on a schedule. That is frequently still a good project. It is a different project, worth a different amount, and the time to discover that is while the scope is being written rather than during acceptance. The same discipline applies here that applies to writing the scope for a build: name the constraint in the document, so the bids you get back are comparable.
Read and suggest, and why a first build is usually read only.
The pattern we default to on a first commission is that the AI layer reads records, does the work, and writes back a proposed action that a person approves inside the system they already use. The system of record stays the system of record. Every change carries a human decision behind it. This is not caution for its own sake, and it is not a limitation to engineer away in phase two. It is what makes a system safe to run during the period when you are still finding out what it gets wrong.
It also has a practical advantage that owners tend to appreciate more than the safety argument. A read-only or read-and-suggest build needs far less from whoever administers the ERP. Read credentials are usually a short conversation. Write permissions on a production financial or operational system are a long one, involving people who are measured on nothing going wrong, and that negotiation routinely takes longer than the software. Starting read-only lets the build ship while that conversation happens rather than behind it.
Direct writes are defensible, and we build them, when the audit trail is structured, the failure cost is bounded, and every write is logged in a form somebody can review. Those builds take longer, because the read and write permissions need real diligence rather than an administrator account handed over on day one, and they ship with a runbook for the edge cases. The question worth settling early is not whether the system is allowed to write. It is what the worst wrong write would cost and who would notice it.
When the honest answer is that the integration is not the project.
Sometimes the four questions come back badly enough that the right recommendation is to leave the system of record alone. That is a real answer and it should be given plainly rather than engineered around.
The clearest case is a migration already in flight. If the records the workflow touches are moving to a new platform inside the next few quarters, building against the outgoing interface means paying for the same integration twice. The nuance operators miss is that this only applies to workflows that actually touch those records. A great deal of the most valuable work in a mid-market operation sits alongside the ERP rather than inside it: quoting, intake, correspondence, document handling, and retrieval over the accumulated material nobody can find. Those are frequently unaffected by a migration, and postponing them for one is a scheduling decision rather than a technical one. It is worth naming which of the two you are making.
The second case is a system with no documented interface, no supported database access and a workflow that genuinely needs to write. Screen automation can be made to work and we would rather tell you that it is a bridge than sell it as a platform. The better move is usually to pick a different first workflow, ship something that pays for itself, and revisit the hard one with a track record behind you. Operators who do that are the ones least likely to be in the month-four stall, because they have a second candidate ready rather than a single bet that has to work.
The third case is a warehouse question wearing an integration costume. If the workflow analyses history and never writes, reading from a reporting database is better than reading from the production system on every axis that matters. That is worth knowing before anyone funds a warehouse programme as a prerequisite to an AI project that needed read access to four tables.
What we look at when an operator asks whether their ERP will cooperate.
We treat the interface review as part of the diagnosis rather than as the first week of the build, because quoting a fixed price against an integration surface nobody has examined is guessing, and we would rather not do that to either party. On the call we go through the four questions against the specific system and the specific workflow, and we ask the operator to request three things from whoever supplies their ERP: the documentation, the ceilings that apply to their licence stated as numbers, and the published end-of-support date for the version they are running.
Two commitments sit behind that, and both are easier to make in writing than to discover later. Whatever gets built is handed over as code you own, for the reasons set out in the piece on code handoff, and the integration is part of the handover rather than a black box that only we can maintain. And the terms that govern the arrangement, including what happens when the platform underneath changes, belong in the agreement rather than in a conversation, which is the subject of what belongs in an AI vendor contract. The same logic that makes a model retirement date a contractual matter makes an ERP retirement date one.
One thing we will not do here is show you a client's integration and tell you what it saved them. Our client agreements carry mutual confidentiality and no publicity clause, so we have no right to name engagements or quote their results, and inventing a number to fill the space would be worse than the gap. What we can tell you is what the vendors publish, which is checkable by you in an afternoon, and what we would recommend for a specific system on a specific workflow, which is what the diagnosis call is for. Our integration playbooks set out the same reasoning per platform, and our fixed-fee bands are published for the same reason we are asking your ERP vendor to publish theirs.
Sources.
Every figure on this page was read on 25 August 2026 from the vendor's own documentation, and the links go to those documents rather than to a summary of them. Business Central: Operational limits for Business Central online and Working with API limits in Dynamics 365 Business Central. Sage Intacct: the XML Web Services overview, error handling, and the developer FAQ. Dynamics GP: Understand the lifecycle policies for Dynamics GP and the Microsoft Lifecycle listing. The Acumatica observation is a request we made ourselves: the help page identified as pageid 7a796856-3dec-4a4f-abf8-171324c9642b returned HTTP 301 to an access gateway with an X-Robots-Tag: noindex header at 13:01 UTC on 25 August 2026. Vendor documentation changes; the date above is when each page was read, not a promise about what it says today. No client result, benchmark population or industry statistic is asserted anywhere on this page.