by Agile-ERPProcurement, budgets and approvals,connected to Priority.
For requesters, approvers and finance teams: every order starts from the budget, goes to the right approvers, and is created in Priority only once approved. The official purchase order lives in Priority.
- Requests are checked against the available budget before they go for approval
- Approvals follow organizational responsibility and authority
- One place to follow an order through goods receipt and the supplier invoice
In use at The Working and Studying Youth (NOAL), with about 320 users.
User count as reported by the organization, October 2026.
Read the case studyPriority Authorized Partner
From recommendation letters
…procurement processes have been standardized, centralized and digitized; control and transparency have been strengthened; and the day-to-day work of our users has become clearer and simpler.
The system is very fast, supports a range of controls, and its management interface is convenient and lets the system administrators work independently.
Translated from Hebrew
What your organization gets
Control over budgets and approvals, without changing Priority
Opero Procurement is where procurement work happens, above Priority: people work in a simple interface, and Priority stays the financial system.
Budget before the order
Requesters see the available balance on the budget line, and an order that exceeds it stops before it goes for approval.
The right approver, every time
The route follows the amount, the org structure and the supplier, with a full history of who approved and when.
Everyone sees their own scope
Each user sees and acts only on the budgets, units and orders they are responsible for.
One official order, in Priority
After final approval, the purchase order is created in Priority — no double entry.
Tracked through goods and invoice
Goods receipt is recorded against the order, and the supplier invoice recorded in Priority is shown alongside it.
Controlled budget changes
Transfers between lines and increase or decrease requests, with balance and permission checks and the budget updated in Priority.
Full detail: approvals, permissions, budget control and reliability
The approval engine
- A route is matched by amount threshold and the request's organizational dimensions — not by a generic role.
- Every approver has an authority level and a responsibility scope, and authority has validity dates.
- A supplier can carry a designated approver who replaces the first approver.
- A rejection returns the request to the requester with the recorded reason.
- Who was responsible for a step and who actually approved it are stored separately.
- A cancellation request runs its own approval route.
- A read-only scenario checker shows which route would apply, without performing anything.
Permissions and responsibility
- A permission profile defines operational scope across organizational dimensions and is assigned to users.
- Assigning users to units, managers and budgets determines what each person sees and what reaches them for approval.
- Permissions are enforced server-side on every query, not just in the menu; separation between organizations holds in exports too.
Budget control
- The balance is checked server-side at submission and again at final approval; an overrun blocks.
- Utilization includes open orders, so a commitment is never counted twice.
- An inactive line, a non-expense line or a line with no utilization data blocks rather than guesses.
- Lines are resolved by the budget line's own year, not the calendar year.
- Budget-transfer management is a module enabled per organization. A transfer changes allocations — it is not a payment.
Reliability with Priority
- Every order carries a reference; a repeated creation attempt returns the existing order instead of creating a duplicate.
- An uncertain result is verified against Priority before any further write.
- An order that was not created, a document that was not produced, or a failed sync is flagged and visible to its owner.
Example approval routes
- 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.
Want to see this on your own procurement process?
How it works
The procurement process and budget management — step by step
Pick a step or a scenario to see what happens, who does it, and what passes between Opero and Priority.
One purchase order all the way through: it is opened and approved in Opero, and becomes the binding order in Priority only after final approval.
Opero Procurement
Step 1 of 5
Open a purchase order
- What happens
- The user opens a purchase order from a budget line in their responsibility scope: supplier, lines, quantities and prices. It stays a draft until it is sent for approval.
- Who acts
- A user entitled to use the budget line.
- What is checked
- Only lines within the user's scope can be picked. While editing, the available balance is shown and an overrun is flagged early.
- With Priority
- Priority → OperoSuppliers, budget lines and exchange rates are synchronized from Priority.
Step 1 of 5: Open a purchase order
All steps as text
The same content as the diagram, in one continuous view.
Procurement process
One purchase order all the way through: it is opened and approved in Opero, and becomes the binding order in Priority only after final approval.
Open a purchase order
What happens: The user opens a purchase order from a budget line in their responsibility scope: supplier, lines, quantities and prices. It stays a draft until it is sent for approval.
Who acts: A user entitled to use the budget line.
What is checked: Only lines within the user's scope can be picked. While editing, the available balance is shown and an overrun is flagged early.
With Priority: Priority → Opero: Suppliers, budget lines and exchange rates are synchronized from Priority.
Budget and permission check
What happens: When the order is sent for approval, the server checks the user's permission on the line and its available balance again.
Who acts: The system, server-side — not only on screen.
What is checked: An overrun or a line without permission blocks submission. Utilization already includes open orders, so a commitment is never counted twice.
With Priority: Priority → Opero: The line's balance is checked against Priority's budget data.
Approval route
What happens: The system determines the route from the amount, the organizational dimensions and the supplier, and passes the order to the approvers in turn. Below a configured threshold, an order can be auto-approved.
Who acts: The approvers on the route, by authority level and its validity.
What is checked: The balance is checked again at final approval. A rejection requires a reason and returns the order to the requester.
With Priority: The route runs entirely in Opero. Nothing has been written to Priority yet.
Purchase order in Priority
What happens: After final approval, the binding purchase order is created in Priority and its number is stored back in Opero. The official PDF is pulled from Priority and emailed to the requester.
Who acts: The system, through the Gateway layer — automatically or at the click of an authorized user, per organization setting.
What is checked: Every order carries a reference. An uncertain result is verified against Priority before another attempt, so no duplicate order is created.
With Priority: Opero → Priority: The purchase order and its lines are written to Priority. Priority → Opero: The order number and the official PDF come back from Priority.
Goods receipt and supplier invoice
What happens: Goods receipt is recorded against the order, and a goods-receipt document is created in Priority. A supplier invoice already recorded in Priority is shown in the context of the order and the receipt, with its invoice number, an “invoice received” status, and the PDF when available.
Who acts: Goods receipt: the requester, an approver whose scope covers the order, or automatically by rules the organization sets. Invoice details are visible to anyone who may view the order; opening the PDF requires a dedicated permission.
What is checked: The invoice is linked to the order through the goods receipt. This is display only: Opero does not ingest invoices from email, does not create or post invoices, and performs no matching or payment.
With Priority: Opero → Priority: The goods-receipt document is written to Priority. Priority → Opero: The supplier invoice and its PDF are read from Priority — read-only.
Budget management
Transfer between lines
A direct transfer between two lines the user is authorized on. It has no approval route: the user checks it, confirms it explicitly and executes it — and the checks run before execution.
Pick source and target
What happens: The user finds the source and target lines right in the field, by code or description, and enters the transfer amount.
Who acts: A user with write permission on both lines.
What is checked: Only lines the user is authorized on are offered. The reserve line can never be the source, and source and target must differ.
With Priority: Priority → Opero: Budget lines are synchronized from Priority.
Transfer check
What happens: Before execution, a comparison is shown: the balance in the procurement system, the current balance in Priority, and the expected balance after the transfer.
Who acts: The system, server-side.
What is checked: Permission on both lines, a transfer rule set by the organization admin between source and target, and enough balance in the source — both in the procurement system and in Priority.
With Priority: Priority → Opero: The source line's current balance is read from Priority.
Execute in Priority
What happens: The user confirms the transfer explicitly, and the budget is updated in Priority: the source allocation goes down and the target allocation goes up by the transfer amount.
Who acts: The user who ran the check.
What is checked: Every check runs again at the moment of execution. Each update is read back from Priority, and a partial result is flagged for reconciliation rather than swallowed.
With Priority: Opero → Priority: Both lines' allocations are updated in Priority's budget plan.
Record and history
What happens: Every transfer is stored with who executed it, when, source, target, amount and state, and the list can be exported.
Who acts: Users see their own transfers; the organization admin sees all of them.
What is checked: A transfer that did not complete in full goes to a recorded follow-up and is never shown as a success.
With Priority: The record and history are kept in Opero.
Increase request
A request to increase a line runs an approval route. The approver funds it from the organization's reserve or from a line they are authorized on — and only then is the budget updated.
Submit the request
What happens: The requester finds the line by searching right in the field, sees its allocation, utilization and balance from Priority, and enters an increase amount or a requested balance — the other field is calculated. A reason is required.
Who acts: A user with write permission on the line.
What is checked: At submission the figures are read from Priority again. If they changed, nothing is saved and the revised calculation is shown.
With Priority: Priority → Opero: Allocation, utilization (open orders included) and current balance.
Approval route
What happens: The request opens with the relevant approval tier and can be passed up to the next tier, following the approval mechanism configured for the organization.
Who acts: The approvers at the active tier.
What is checked: An approver can reject with a reason, or approve a lower amount than requested — never a higher one.
With Priority: The route runs entirely in Opero.
Fund the request
What happens: The approver chooses the funding source: the organization's central reserve line, or a line they are authorized on themselves.
Who acts: Reserve funding — approvers authorized for it. Line funding — an approver with permission on the funding line.
What is checked: The funding source's balance is checked in the procurement system and in Priority. What is approved is a fixed amount.
With Priority: Priority → Opero: The current balance of the funding source.
Execute in Priority
What happens: Budget moves from the funding source to the requested line, and the budget plan is updated in Priority.
Who acts: The system, following the approver's funding action.
What is checked: The checks run again at execution, and each request results in exactly one transfer.
With Priority: Opero → Priority: The funding source's and the requested line's allocations are updated in Priority.
Tracking and notifications
What happens: The request history shows who handled it, who passed it on, and what was approved. Emails go out when a step opens, and on rejection, funding and cancellation.
Who acts: The requester and the relevant approvers.
What is checked: Only the requester can cancel an open request.
With Priority: History and notifications are managed in Opero.
Decrease request
A request to return budget a line no longer needs to the organization's reserve line. It runs the approval route, and approval performs the return.
Submit the request
What happens: The requester picks the line to decrease and enters a decrease amount or a requested balance — the other field is calculated from Priority's figures. A reason is required.
Who acts: A user with write permission on the line.
What is checked: A line cannot be decreased by more than its current balance, which already includes open orders. The reserve line itself cannot be decreased.
With Priority: Priority → Opero: Allocation, utilization (open orders included) and current balance.
Approval route
What happens: The request runs the approval route configured for the organization, and can be rejected with a reason.
Who acts: The approver at the active tier, or an authorized budget-request approver.
What is checked: The funding actions of an increase request are not available here — the destination is always the reserve.
With Priority: The route runs entirely in Opero.
Approve and return to reserve
What happens: Approval performs one transfer from the line to the reserve line, and the budget plan is updated in Priority. A lower amount than requested can be approved.
Who acts: The approver.
What is checked: The line's balance is checked again, in the procurement system and in Priority, at the moment of execution.
With Priority: Priority → Opero: The line's current balance. Opero → Priority: The line's and the reserve's allocations are updated in Priority.
Tracking and notifications
What happens: The request history shows who handled it and what was approved, and emails accompany its steps.
Who acts: The requester and the relevant approvers.
What is checked: Only the requester can cancel an open request.
With Priority: History and notifications are managed in Opero.
How the calculation works
Illustration only — this is not customer data.
- Allocation: ₪40,000 · Utilization (open orders included): ₪28,000 · Current balance: ₪12,000
- Increase amount: ₪4,000 · Requested balance after the change: ₪16,000
- Decrease amount: ₪3,000 · Requested balance after the change: ₪9,000
- Balance = allocation − utilization. Open orders are already part of utilization, so they are not deducted a second time.
The product itself
What day-to-day work looks like
Screenshots of the application (Hebrew interface), with demo data only.
Opero in action
The integration
Priority remains the source of truth
Opero Procurement keeps no books of its own: it reads what the process needs from Priority, and writes the binding documents back only after approval.
Read from Priority
- Suppliers and their master data
- Budget lines, utilization and balances
- Exchange rates
- The official order document (PDF)
- Supplier invoices already recorded in Priority
Written to Priority
- Purchase orders, after final approval
- Goods-receipt documents
- Cancellation records
- Budget updates from transfers and approved requests
Opero Procurement is currently available with native Priority ERP integration. Integration with additional ERP platforms can be delivered as a dedicated implementation.
From ERP core to modern operations
The product family
The Opero family
Opero Procurement is the product available today in the Opero family — operational layers above the ERP.
- Available
Planned
Planned
Available today: Opero Procurement. Opero CRM and Opero Flow are planned directions and are not available today. These are selected directions, not the complete roadmap.
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 where procurement work happens, 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. Opero Procurement pays off when approval routing and permissions are complex, 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, and a supplier can carry a designated approver. Thresholds and dimensions are configured per organization.
Can users have different budget and organizational scopes?
Yes. The permission profile and responsibility scope determine which budget lines and units each user sees and may act on, and the rule is enforced server-side.
Where is the final purchase order stored?
In Priority. The order is created there only after final approval, and its number is stored back in Opero. The official Priority PDF is emailed to the requester, and can be shared with the supplier over WhatsApp where the organization has enabled it.
How do budget transfers and increase or decrease requests work?
A direct transfer between lines is executed by a user authorized on both lines, after permission, transfer-rule and balance checks. Increase and decrease requests run an approval route: an increase is funded from the reserve or from an authorized line, and a decrease returns budget to the reserve. In every case the allocations are updated in Priority.
Can we view supplier invoices from within the system?
Yes. The supplier invoice is recorded in Priority as usual and shown in Opero in the context of the order and the goods receipt: the invoice number, its status, and the PDF when it is available and the user is authorized. Recording and processing the invoice stay in Priority.
Can people work from a phone?
Yes. Requesters and approvers can submit requests, approve, view budgets and track orders from a phone. The system runs in the browser and adapts to the phone screen — there is no app to install.
Is this custom development or a product?
A product. Opero Procurement is a multi-organization platform running in production, and fitting it to an organization is configuration: order structure, budget level, hierarchy labels and approval routes.
Next step
Let's see it work on your procurement process
A short demo against a real process from your organization: who requests, who approves, and on what basis. Prefer that we call you? Leave your details.
Book a demoor
We'll call you back
Leave a phone number or email, and we'll get back to you shortly.