Invoice approval in Bitrix24 (Alaio) is built with three tools: the ready-made "Payment invoice" process in the feed — for simple companies, a smart process with a Kanban — when you need routes and reporting, and a business process — when the logic depends on the amount and the org structure. The choice depends on payment volume and route complexity. Let's go through all three and assemble a working scheme that doesn't fall apart over vacations and holidays.
Which tool should you choose for invoice approval?
The feed process ("Processes" → "Payment invoice") works out of the box: an employee fills in a form — counterparty, amount, purpose, the invoice file — and the request travels a fixed chain of approvers to the accountant. It works while there's one chain for everyone and few payments. A smart process is a Kanban of payment requests with stages like "New → With the manager → With the CFO → In payment → Paid": you can see the workload, the bottlenecks, and the history; the routes are configured with robots on the stages. A business process adds branching: the route depends on the amount, the budget line, the counterparty. A practical guideline: up to 30 invoices a month — the feed; more than that, or if you need reporting — a smart process; routes with conditions — a smart process plus a business process on the stages.
How do you assemble an invoice-approval smart process step by step?
Create an "Invoice approval" smart process (CRM → Settings → Smart Processes) with business processes enabled. Fields: counterparty (a link to the company), amount, payment purpose, the invoice file, payment due date, budget line. Stages — by the route: "New request", "Check", "Manager approval", "Financial approval", "To be paid", "Paid", "Rejected". On the stages — robots: at "Check", Compound condition verifies completeness (amount, file, budget line) and returns the request with a task if something is missing; at "Approval" — a notification to the approver and a control deadline. Requests are created manually from the Kanban or automatically from a deal by a business process.
How do you make a route by amount without hardcoding people into the template?
The classic rule "up to 50,000 the department head approves, above it the CFO" is assembled from two robots. Compound condition compares the amount with the threshold (keep the threshold in a process constant — when the limit changes you won't have to redraw the scheme). Look up the approver not by name but by the org structure: the Get employee manager robot returns the request author's manager — one template works for all departments, and one specific person's vacation doesn't stop payments (the backup approver is the manager's manager, via the same robot).
How do you control payment deadlines?
The deadline "pay within three days" has to become a concrete date, and pauses here are counted in calendar days: three days from a Thursday is a Sunday, and the escalation fires into an empty office. The Nearest date by condition robot takes the approval date and returns the nearest working day — or the end of the month, when payments are batched. Write the control date into a request field: an overdue-payments report is built from it. A parallel branch of the process waits for the control date and, if the request isn't yet "In payment", sends a reminder to the approver and an escalation to their manager. The payment order and the letter to the counterparty are generated from a document template, which merges the amount, the counterparty's details and that same control date straight out of the request's fields.
Common mistakes in invoice approval
Approving in chats: the "go ahead and pay" decision lives in the conversation, with no trace in the system — afterward you can't reconstruct who authorized the payment. One route for all amounts: the CFO drowns in small invoices, while large payments wait in the common queue. A control date set with no slack — escalations fire on weekends. No "Rejected" stage with a reason: requests vanish silently, and employees recreate them. And no link to the deal: the invoice is approved, but you can't see it in the deal — link the request to the CRM entity through a link field.
In summary
The feed is for getting started, a smart process is for order, a business process is for routes by amount and structure. The route's bricks — a condition by amount, the manager by org structure, the control date — are already in the Roboteka catalog, install for free, and work in any of the three variants.