Why Priority ERP is both the opportunity and the challenge
Priority Software is Israel's homegrown ERP - it powers many Israeli businesses across manufacturing, wholesale, healthcare, and services. That ubiquity makes it a logical target for AI augmentation: if a company already tracks orders, customers, and inventory in Priority, an AI agent that can read and act on that data can eliminate large amounts of manual work.
The challenge is that Priority was designed as a structured transaction system, not as an AI-friendly data platform. Its data model is complex, its business logic is often encoded in customized Priority Procedure Language (BPL) scripts, and the REST API - while solid - doesn't expose every entity or every custom field that local implementations have added over years of use.
This creates a gap between what sounds simple ("just connect ChatGPT to our Priority") and what's actually required. Bridging that gap is the work.
The two technical paths: REST API vs. SQL middleware
Path 1 - Priority REST API (preferred)
Priority version 21+ ships with a REST API that follows OData conventions. You authenticate via OAuth2, query entities like ORDERS, CUSTOMERS, PRICELIST, and IVFROMFP (invoices), and post new records. For an AI agent, this means clean read/write access without touching the database directly.
The practical limitation: not every custom field, sub-form, or company-specific procedure is exposed. If your Priority implementation has years of local customizations - common in Israeli mid-market companies - the API may not give you everything the agent needs. The rest requires either extended API configuration (a Priority developer task) or a supplemental SQL read for the gaps.
Path 2 - MS SQL middleware
Priority runs on Microsoft SQL Server. For older versions or heavily customized implementations, some integrators read directly from the SQL database via a middleware service. This gives full access to all data, but comes with risks: table names and schemas change across Priority versions, writing directly to the database bypasses Priority's business-logic validation, and it creates a maintenance dependency on your Priority version upgrade path.
Best practice: use the REST API as the primary interface and fall back to read-only SQL queries only for data the API doesn't expose. Never write to Priority's SQL database directly - always use the API or Priority's built-in import interfaces for writes.
Five AI use cases that actually work with Priority
These are patterns built in the Israeli market, not theoretical possibilities:
- Customer service agent with live inventory: A WhatsApp or web chat agent that answers customer questions ("what's the delivery date for order 12345?", "do you have item X in stock in size Y?") by querying Priority in real time. Read-only, low risk, high value.
- Automated order entry from unstructured sources: Customers send orders via WhatsApp, email, or PDF. The AI agent extracts the items, quantities, and customer details, validates them against Priority's price list and customer records, and creates the order - or flags exceptions for a human. Reduces data-entry labor significantly in wholesale and distribution companies.
- Invoice processing and AP automation: Supplier invoices arrive as PDFs. The AI extracts line items, matches them against open purchase orders in Priority, and either posts the invoice or routes discrepancies for review. Common in manufacturing and retail.
- Supplier communication agent: The agent monitors Priority for low-stock items, drafts purchase orders, sends them to suppliers via email, and updates Priority when confirmations arrive. Requires reliable business-logic rules to avoid over-ordering.
- Internal knowledge agent over Priority + documents: Employees ask questions like "what's our standard payment term for customer segment B?" or "find all open orders from supplier X this quarter" - the agent queries both Priority and your internal document store. This is a use case for a knowledge-base AI agent like DocBrain, combining structured ERP data with unstructured documents.
What the actual build involves
A Priority AI integration project has four phases, regardless of which use case you're targeting:
- API audit: Map which Priority entities the AI needs to read and write. Identify gaps between what the API exposes and what the business process requires. This is often the most revealing phase - it surfaces complexity that wasn't visible upfront.
- Business logic mapping: Priority's pricing, approval, and validation rules need to be translated into rules the AI agent can follow. This isn't code - it's structured documentation of "if a customer is in segment A and the order is above a set amount, apply pricing tier 3" - and it requires input from the people who actually know how the business works.
- Agent development and integration: Build the agent, connect it to Priority via the API, implement error handling for API failures and edge cases, and build the human-escalation path for cases the agent can't handle confidently.
- Testing and rollout: Parallel operation (agent runs alongside humans, humans verify outputs), then gradual handover. Priority integrations are not "launch and leave" - the first weeks of live operation always surface edge cases.
Where it fits - and where it doesn't
AI + Priority works well when: the process is high-volume and repetitive (order entry, invoice matching), the data in Priority is clean and up to date, and there's organizational willingness to maintain the business-logic rules over time.
It's a poor fit when: Priority data quality is poor (garbage in, garbage out), the process has too many exceptions to encode reliably, or the company expects a zero-maintenance system. AI agents over ERP require ongoing maintenance as business rules evolve - plan and budget for ongoing maintenance.
It's also not a substitute for a proper AI integration strategy. The Priority connection is one component; the agent orchestration, error handling, and human oversight layer are equally important and often underestimated. For a broader view of how AI agents fit into business operations, see AI Agents for Business in 2026.
What drives the cost
| Scope | What's included | What drives the cost |
|---|
| Focused single workflow (read-only) | Customer service or inquiry agent, REST API, no writes to Priority | How many Priority entities it reads and how many kinds of inquiries it handles |
| Single workflow with writes | Order entry or invoice posting agent, API + validation layer | Validation rules and error handling for every write |
| Multi-workflow integration | Several connected agents, shared API layer, complex business logic | Number of agents and how much business logic has to be mapped |
Actual cost and timeline depend heavily on the state of your Priority implementation, how much custom BPL logic needs to be mapped, and whether the REST API covers your required entities or SQL middleware is needed.
For context on how these costs compare to broader AI integration projects, see AI Integration for Business in Israel 2026 and Custom CRM Development Cost 2026.
How to start
The first step is always an API audit: give a developer a few days to connect to your Priority REST API and pull the entities your target process needs. This is low-cost discovery that tells you whether the clean path (REST API) works or whether you're heading into middleware territory - and that shapes the entire project budget and timeline.
If you're evaluating whether an AI agent over Priority makes economic sense for your business, the AI Blueprint is a structured way to scope it before committing to a full build.
FAQ
Does Priority have an official AI integration?
Priority Software has been adding AI features to its own product (Priority AI, announced in 2024), but these are built-in features for Priority users - not a framework for connecting external AI agents to Priority data. Custom AI agents that use Priority as a data source still require custom development against the REST API.
Can I use ChatGPT or Claude directly with Priority?
Not directly - these are language models, not integration platforms. You can use them as the AI brain inside a custom agent, but you still need the integration layer (API connection, business-logic rules, error handling) built around them. The LLM is one component, not the whole solution.
What Priority version do I need?
The REST API is available from Priority version 21 (released 2019). Most Israeli companies running Priority are on a supported version that includes it. If you're on an older version, a Priority upgrade may be a prerequisite - or you'll need the SQL middleware path, which has higher long-term maintenance costs.
How long until the AI agent pays for itself?
It depends on how much manual work the agent replaces. A customer service agent that answers inquiries which currently need a person to look up Priority data pays back through saved staff time. An order-entry agent pays back through less manual data entry and fewer errors. Actual payback depends on your current labor cost and error rate.
Do you need a Priority consultant or an AI developer?
Both. The Priority-side work (API configuration, entity mapping, BPL rule documentation) is best done by someone who knows Priority deeply. The AI agent architecture and LLM orchestration is a different skill set. Most projects use a Priority consultant for the discovery and mapping phase and an AI development team for the agent build.
What's the alternative to building a custom agent?
The main alternatives are: (1) using Priority's own built-in automation features and workflows (free but limited); (2) low-code platforms like Make.com or n8n that have some Priority connectors (faster but less capable for complex logic); or (3) waiting for Priority Software to ship AI features that cover your use case. For high-volume, high-value processes, custom agents typically outperform all three alternatives.
If you're running Priority and have a specific process in mind, book a consultation - it's the fastest way to get a realistic scope and cost for your situation.
