Invoice approval in Bitrix24 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 working days" is calculated by the Date + N working days robot from the approval date — against the production calendar, with no surprises over the May holidays. 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. For the payment order and the letter to the counterparty, the amount in words is produced by the Amount in words (RUB) robot — the result is inserted into the document template.
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 3,000-ruble invoices, while large payments wait in the common queue. Deadlines in calendar days — 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, working days, the amount in words — are already in the Roboteka catalog, install for free, and work in any of the three variants.