Azure OpenAI Service is the common choice for Acumatica customers already standardized on Microsoft's stack — Entra ID for auth, Azure Functions for the integration layer, and now a regionally-hosted GPT deployment instead of a call to OpenAI's public endpoint. The agent architecture underneath doesn't change; what changes is where the model lives and how it's provisioned.
Deploying a model, not just calling an API
Unlike OpenAI's API, Azure OpenAI requires you to provision a deployment of a specific model version in a specific region first, then call it by deployment name rather than model name directly. That extra step is also the point: it gives you data residency guarantees, private networking through VNet integration, and Azure RBAC controlling who can call the deployment — meaningful for ERP customers in regulated industries or jurisdictions with data residency requirements.
from openai import AzureOpenAI
client = AzureOpenAI(
azure_endpoint="https://your-resource.openai.azure.com/",
api_key=os.environ["AZURE_OPENAI_KEY"],
api_version="2024-10-21"
)
resp = client.chat.completions.create(
model="gpt-4o-ap-automation", # deployment name, not model name
messages=[{"role": "user", "content": "Summarize this AR aging for review."}],
tools=[get_ar_aging_tool_spec]
)Function calling works the same way
Azure OpenAI's function-calling (tool-use) shape mirrors OpenAI's own API — the model returns a tool_calls array with a function name and JSON arguments, your code executes it against Acumatica's REST API, and the result goes back in the next message. The same discipline applies regardless of host: narrow tool schemas, read/write separation, and human approval before anything posts a transaction in Acumatica.
Azure OpenAI applies content-filtering policies by default that can flag business text containing terms around "collections," "write-off," or aggressive customer language as a false positive. Test your prompts against the default filter configuration before launch, and adjust the content filter policy for the specific deployment rather than working around it by rephrasing prompts unpredictably.
Entra ID for service-to-service auth
Instead of managing an API key, Azure OpenAI supports Entra ID (Azure AD) token-based authentication for service principals — useful if your Acumatica integration layer already authenticates to other Azure services (Blob Storage, Service Bus) the same way. It keeps one fewer long-lived secret in your integration's configuration.
Cost tracking per workload
Azure Cost Management can attribute spend to a specific OpenAI deployment and resource group, which matters if you're running several agent workloads (AP automation, AR collections drafting, bank reconciliation) against the same Azure subscription and need to know which one is actually earning its token cost.
Wrapping up
Azure OpenAI is the same function-calling architecture as the native OpenAI API with a deployment and networking layer wrapped around it for enterprise compliance. Choose it when Entra ID, VNet isolation, or data residency are already requirements for your Acumatica customer — not because the model behaves differently. If you are stuck on something specific, reach out or keep reading through the rest of the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.