Opero-Procurement by Agile-ERP
Priority stays the system of record.Procurement works the way your organization does.
An operational layer above your ERP that governs who may request what, against which budget, through which approval route, and at which authority level — while the official purchase order is still created in Priority, and stays there.
Already in production across two organizations.
People and process
Request, approve, track, receive
Opero-Procurement
Entitlements · Responsibility scope · Budget · Approval routes
Priority ERP
Financial and organizational source of truth
The problem
Where does the work actually happen?
The ERP holds the data. In most organizations, the gap between that system and the daily work gets filled with tools that are hard to govern, audit, and keep in sync.
Today: work outside the system
- Budget spreadsheets
- Email requests
- Messaging threads
- Phone follow-up
- Verbal approvals
- Double entry
Opero-Procurement
Priority — system of record
- Budget spreadsheets circulating between departments
- Purchase requests arriving by email and messaging apps
- Approvals that depend on who replied first
- The same order keyed twice — once in a file, once in the ERP
Each one is a workaround. In a growing organization, workarounds become the bottleneck.
Not a prototype
Software that runs in production
Opero-Procurement is not a concept or a slide deck. It is a live system, already in production across two organizations, handling real procurement from budget through goods receipt.
A product, not a bespoke project
A multi-organization platform. What looks like customization is configuration: order structure, budget level, hierarchy labels, and approval routes are defined per organization.
Checks block, they don't advise
An on-screen indication is not a substitute for a check. The binding check runs server-side, at submission and at final approval.
Built for RTL Hebrew, and for mobile
Not a translated interface — one built in Hebrew from the start, including on a phone.
The material difference
The transaction versus the operational context
An ERP is built around the document: which supplier, which item, which amount. Opero-Procurement is the layer above it — the one that decides whether that document should exist at all, who may bring it into being, and along which route.
What a purchasing document describes
Transaction layer
- Supplier
- Item and pricing
- Amount and currency
- Document and order
- Accounting entry
What determines whether and how the document is created
Operational context
- Who this user is in the organization
- Which responsibility scope they own
- Which budgets they may draw from
- What they are allowed to see
- What they are allowed to initiate
- Who is responsible for approving this request
- Which approval route applies in this context
- Which authority level is required
Priority does not change. Organizations do not have to restructure their ERP to run the operational layer, and there is no parallel order book: the official purchase order is created in Priority and stays there.
The approval engine
An approval route does not have to be user → manager → ERP
The route is derived from context: the amount, the request's organizational dimensions, the relevant authority levels, and the supplier. The same request, in a different context, routes differently.
- Budget check
- Auto-approved
- Budget check
- First approver
- Budget check
- First approver
- Second approver
- Budget check
- Designated approver
- Continue by threshold
Illustrative only. Thresholds, organizational dimensions, and authority levels are configured per organization.
Routing by amount and org structure
A route is matched by amount threshold and by the request's organizational dimensions — not by a generic role.
Authority levels and validity
Every approver carries an authority level and a responsibility scope, and authority carries validity dates — an expired approver does not approve.
Supplier-designated approver
A supplier can carry a designated approver who replaces the first approver in the route.
Rejection with a reason
A rejection returns the request to the requester for editing, with the recorded reason attached.
Full approval history
Who was responsible for a step and who actually approved it are stored separately — because they are frequently not the same person.
Test a route before you commit
A read-only scenario checker shows which route would apply, without performing anything.
Cancellation has its own route
A cancellation request runs its own approval route rather than riding on the original approval.
No silent re-routing
A route that cannot be reconstructed is returned as an explicit configuration error instead of being quietly re-picked.
Want to see this against a real process of your own?
Book a demoEntitlements and responsibility
Not just Admin and User — entitlements that follow your org structure.
Most systems ask what role a user has. Opero-Procurement asks what they are responsible for — and derives from that what they see, what they may initiate, and what reaches them for approval.
Permission profiles
A profile defines operational scope across organizational dimensions and is assigned to users, instead of being rebuilt for each person.
Responsibility scope
A user sees and acts only within their defined scope — the budgets, units, and requests they own.
Operational assignment
Users are associated with organizational units, managers, and budgets. Operational visibility is derived from that, not from the menu.
Authority levels and validity
An authority level per user, with validity dates — so temporary authority does not stay open indefinitely.
Entitlements are infrastructure, not concealment: they are enforced server-side on every query, so a screen that is hidden from the menu is also blocked on direct access. Separation between organizations holds on every query and every export.
Budget control
People start from the budget — not from the document
This is the actual order of operations, not a slogan. Instead of building a request and only then discovering there is no cover, the requester first sees what is genuinely available to them.
See your own budget
Only the lines within your responsibility scope — allocated, used, and available.
Pick a line that has balance
One with money genuinely available, resolved against the budget line's own year rather than the calendar year.
Create the request from that line
The request is born inside its budget context instead of searching for one afterwards.
The check blocks
An overrun stops submission. The binding check runs server-side, not only on screen.
Allocated
Available
Overrun — submission blocked
It fails closed: an inactive line, a line that is not an expense line, or a line with no utilization data blocks rather than guesses. Management sees the same picture without asking anyone for a report.
How it works
From budget to a Priority purchase order — in one process
Every step is recorded and synchronized. No duplicate manual entry, and no step that happens outside the system.
A user creates a request
OperoFrom a budget line they are entitled to use, with supplier, lines, and pricing.
Entitlement and scope are resolved
OperoThe permission profile and responsibility scope determine what they may initiate, and over what.
Budget is checked
OperoAvailable balance is verified against synchronized utilization data. An overrun blocks.
The approval route is determined
OperoBy amount, organizational dimensions, and the authority levels required.
Approvals are completed
OperoEach step is recorded: who was responsible, who actually approved, and when.
A binding PO is created in Priority
PriorityOnly after final approval. The final order number is stored back into the system.
The order document reaches the supplier
PriorityThe official PDF is pulled from Priority and emailed to the supplier.
Goods receipt and synchronization
PriorityReceipt is recorded against the order, a goods-receipt document is created in Priority, and utilization updates on sync.
Failures are not swallowed: an order that was not created, a document that was not produced, or a sync that failed is explicitly flagged and visible to whoever owns it.
The integration
Priority remains the source of truth
Opero-Procurement keeps no books of its own. It reads the master data the process needs from Priority, and writes the binding documents back to it — after approval is complete.
Read from Priority
- Suppliers and their master data
- Budget lines
- Budget utilization and balances
- Exchange rates
- The official order document (PDF)
Written to Priority
- Purchase orders, after final approval
- Supplier goods-receipt documents
- Cancellation records
The principle behind every financial action
An uncertain communication error does not mean the action did not happen. The system checks against Priority before writing again — because a duplicate document in the ERP costs more than one extra check.
Opero-Procurement is currently productized for Priority ERP. Integration with additional ERP platforms can be delivered as a separate implementation.
FAQ
What people ask before a demo
Does Opero-Procurement replace Priority?
No. Priority remains the core system and the source of truth, and every binding financial document is created there. Opero-Procurement is the operational working layer above it.
Why not use the standard Priority purchasing screens?
If they cover your process and people work well with them, stay with them — and we will say so in the meeting. A layer that does not solve a real problem is just another system to maintain. It pays off when approval routing, entitlements, and organizational responsibility are more complex than the standard process was designed for, and when many of your users are not ERP people.
Can approval flows reflect our organizational structure?
Yes. A route is matched by amount threshold and organizational dimensions, with authority levels and responsibility scopes. A supplier can carry a designated approver who replaces the first approver. Thresholds and dimensions are configured per organization.
Can users have different budget and organizational scopes?
Yes. The permission profile, responsibility scope, and operational assignment determine which budget lines and which organizational units each user sees and may act on. The rule is enforced server-side, not just in the menu.
Where is the final purchase order stored?
In Priority. The order is created there only after final approval, and the order number is stored back into the system. The official order document is the Priority PDF.
How do you prevent duplicate orders in Priority?
Every order carries a reference. A repeated creation attempt recognizes that an order already exists for that reference and returns it instead of creating a second document. An uncertain result is verified against Priority before any further write.
Is the system suitable for mobile users?
Viewing budgets, tracking orders, and approving work on a phone. Creating a new request and the administrative screens are more comfortable on a wide screen.
Is this custom development or a product?
A product. Opero-Procurement is a multi-organization platform already in production across two organizations. Fitting it to an organization is configuration — order structure, budget level, hierarchy labels, approval routes, and goods-receipt rules.
Let's map your approval and procurement workflow.
A short demo against a real process from your organization: who requests, who approves, on what basis, and where control is being lost today. No 40-slide deck.