Odoo Sign & Approval Workflows: A Practical Guide

A purchase order for a critical spare sits in a manager’s email for four days. The manager is travelling, and the email is somewhere below a hundred others. Production waits. When the approval finally arrives, it arrives as a reply saying “ok go ahead” — which is not an approval record, it is a sentence in a mailbox that nobody will ever find again.

Two months later an auditor asks who authorised that purchase. Somebody searches their email.

This is the normal state of approvals in a mid-sized business, and it persists after an ERP goes live because approvals were treated as a change-management afterthought rather than as part of the implementation. The system holds the purchase order. The authorisation happens outside it.

This article covers two related things: the approval controls Odoo gives you natively, and Odoo Sign for documents that need a signature rather than an internal approval. It is written for operations heads, finance controllers, HR leads and IT managers already running Odoo or evaluating it.

The Problem: The Approval Is the Process, and Nobody Owns It

• Approvals happen in email, so they are not records. A reply saying “approved” has no structure, no timestamp anyone trusts, and no link to the document it approved.
• Nobody knows what is waiting. There is no queue. A request that has stalled is indistinguishable from a request that was never sent, until somebody chases it.
• Authorisation limits exist on paper only. A delegation-of-authority matrix sits in a policy document. The system does not enforce it, so compliance depends on people remembering what their limit is.
• Signature turnaround is measured in days. A contract is emailed, printed, signed, photographed at an angle and sent back. The document that results is a picture of unknown provenance.
• Documents are re-typed to be sent out. The order is in Odoo; the agreement is typed in Word from the order; the two diverge.
• Executed documents live in mailboxes. Finding the signed version of a two-year-old vendor agreement is an archaeology exercise.
• Approvers approve without seeing anything. The request arrives as a subject line and an amount. The approver has no view of the budget position, the vendor history, or what was approved last month.
• Absence stops everything. One approver on leave halts a category of transactions because there is no delegation mechanism.

Why Approval Delay Costs More Than It Looks

Approval time is lead time. Every day a purchase order waits is a day added to procurement lead time, which is a day added to production planning, which becomes safety stock. Businesses carry inventory to absorb their own internal delays, and that inventory has a cost that nobody attributes to the approval process.

Signature delay holds revenue. A signed contract is frequently the trigger for scheduling, provisioning and invoicing. A week between verbal agreement and executed document is a week of deferred cash, repeated across every deal.

Unenforced limits are an audit finding waiting to happen. A control that exists in policy but not in the system is not a control. External auditors and internal audit both treat it that way, and remediation after the finding is more expensive and more disruptive than configuration before it.

Missing records are worse than missing controls. When something goes wrong — a disputed purchase, a vendor claiming authorisation, a price nobody agreed — the question is always what was authorised, by whom, and when. Email cannot answer it reliably.

Management time is consumed by chasing. Somebody in every business spends a meaningful part of their week asking people to approve things. That work disappears when there is a queue with ageing visible.

Approvals Inside Odoo: What You Get Without Building Anything

A useful amount of approval control ships with Odoo. The mistake most implementations make is not knowing it is there and building something instead.

• Purchase double validation. Odoo supports a second approval step on purchase orders above a configurable amount. Below the threshold a buyer confirms the order directly; above it, a designated approver must validate. This single setting encodes the most commonly needed financial control.
• Expense approval. Expense reports route to a manager for approval and then to finance for posting, which separates the two decisions — is this a legitimate business expense, and is it correctly accounted for.
• Time off approval. Leave requests route to the approver defined on the employee record, with a visible queue and calendar impact.
• Sales order and quotation controls. Discount limits and confirmation rights can be restricted by access group, so a large discount requires someone with the group that permits it.
• Credit limits. Customer credit limits can block or warn on order confirmation, which is an approval control in a different form — it forces a decision rather than allowing an exposure to accumulate quietly.
• Inventory adjustment and scrap. Stock adjustments can be restricted to users with the appropriate rights, which matters because an unapproved inventory adjustment is an unapproved write-off.
• Manufacturing and quality gates. Quality control points can block a step until a check is passed, which is an approval expressed as a process gate.
• Studio-built approval steps. For anything the standard apps do not cover — a custom object needing sign-off, a multi-level matrix, a conditional route — Odoo Studio can add states, buttons and automated actions. This works, and it is also where customisation debt accumulates, so it needs governing rather than just doing.

Be honest about the gap. Odoo’s native approval coverage is good in purchasing, expenses and HR, thinner elsewhere, and it does not ship with a general-purpose approval engine where you configure a matrix of amounts, categories and approvers in one place and have it apply everywhere. A business with genuinely complex delegation of authority — several tiers, category-specific approvers, delegation during absence, escalation on ageing — will need deliberate design work. Anyone telling you that is a checkbox has not built one.

Caution: Approval features and their behaviour vary between Odoo editions and versions. Confirm what is available in your edition and version before designing around a specific mechanism.

Odoo Sign: What It Actually Does

Odoo Sign handles documents that need a signature from someone — often someone outside your organisation — rather than an internal state change.

• Templates with placed fields. A document is uploaded once, signature, initial, date and text fields are positioned on it, and it becomes a reusable template. Employment contracts, NDAs, vendor agreements, delivery acceptances and consent forms are all template candidates.
• Signature requests with a defined order. Requests go to one or several signatories, either in sequence — internal signatory first, counterparty second — or in parallel.
• Automatic field population. Fields can be filled from the record the document relates to, so the customer name, address and order value come from the database rather than from somebody’s typing.
• Reminders and expiry. Outstanding requests can be chased automatically and given a validity window, so a document does not sit open indefinitely.
• In-person signing. For a customer in front of you, the document can be signed on a device on the spot.
• A completion record. The executed document is stored with a log of who signed, when, and in what order, attached to the record it belongs to.
• Integration with the rest of Odoo. The value of Sign living inside the ERP is that it can be triggered by, and attached to, a record — an employment contract from a new employee, a vendor agreement from a purchase requisition, an acceptance document from a delivery order. The document ends up on the record rather than in a mailbox.

What it is not. Odoo Sign is a signature and workflow tool. It is not contract lifecycle management — there is no clause library, no obligation tracking, no renewal risk register, no negotiation redlining. A business with heavy contract negotiation volume and real contract risk management needs a CLM product alongside it, and pretending otherwise leads to a Studio project that never finishes. Availability of Sign and specific signer authentication options also varies by edition, hosting and region — confirm before you plan around a particular method.

Legal Validity, Handled Honestly

This is the question that stops projects, and it deserves a careful answer rather than a confident one.

The general position. Most major jurisdictions, including India, the UAE and the United States, recognise electronic signatures as capable of binding a party. Most of those frameworks distinguish between a basic or simple electronic signature and a higher-assurance form — variously described as advanced, qualified or certificate-based — and reserve the higher form for particular transaction types or give it stronger evidentiary weight.

Exclusions exist everywhere. Commonly excluded or restricted categories include certain property and land instruments, wills and testamentary documents, some powers of attorney, negotiable instruments, and anything requiring notarisation or physical attestation. Some jurisdictions also impose stamping or stamp duty obligations that an electronic signature does not remove — the signature may be valid while the instrument is still unstamped and therefore unenforceable or penalised.

What this means practically. Do not make a blanket decision to digitise all signatures. Make the decision by document class. For each class, establish whether an electronic signature is acceptable in the relevant jurisdiction, which assurance level is needed, and whether any stamping or registration obligation attaches. Some classes will be straightforward — internal acknowledgements, NDAs, standard commercial agreements. Some will not.

Techvaria is not a legal adviser. We implement the tooling and the workflow. Whether a given document class can be executed electronically in your jurisdiction is a question for your own counsel, and it should be answered before you switch that class over rather than after.

One further practical point. A counterparty can simply refuse. Some government bodies, banks and large institutional buyers still require wet ink on particular documents regardless of what the law permits. Your process needs a paper path for those cases, not an argument.

Designing the Workflow Instead of Digitising the Signature

Here is the mistake almost everyone makes: they digitise the last step of a process whose earlier steps are the actual bottleneck.

The signature is rarely where the time goes. The time goes in preparing the document, getting internal agreement on its terms, routing it to whoever must review it before it leaves the building, handling the counterparty’s proposed changes, and getting a revised version agreed. Replace the print-and-scan step and you may find the cycle time barely moves, because you optimised a step that took two hours out of a process that took nine days.

So design the whole route:

• Who prepares it, from what source data, using which template.
• Who reviews before dispatch. Commercial terms, legal terms, pricing — and whether those are sequential or can run together.
• What the internal approval threshold is. Not every document needs a director; some need two.
• What happens when the counterparty wants a change. This is the step most workflows ignore, and it is where documents go to die. Define who can accept a change, what change requires re-approval internally, and how the revised version is version-controlled so the wrong draft is not executed.
• Where the executed copy is stored, attached to which record, and for how long it must be retained.
• What happens when an approver is absent. A delegation mechanism, or an escalation after a defined period. Without one, leave stops the process.

Document Generation From ERP Records

The second half of the value is generating the document from the system rather than typing it.

Odoo’s reporting engine produces documents from records — quotations, orders, invoices, delivery notes, work orders — as templated output driven by data. Extending that to agreements and letters means the document carries the data the system holds, not a retyped version of it.

Why this matters more than it sounds: every manual re-entry is a divergence risk. The order says one delivery date and the agreement says another because someone typed it on a different day. When the customer disputes, you have two documents from the same company saying different things.

What to generate rather than type: order confirmations and acceptance documents, standard terms attached to an order, employment contracts from employee records, offer letters from recruitment records, vendor agreements from vendor records, delivery acceptance forms from delivery orders, and service reports from field or repair jobs.

Where the limits are. Heavily negotiated documents with bespoke clause structures are not template output. Generate the standard ones; handle the negotiated ones as documents in their own right. Knowing which is which is a commercial judgement, not a technical one, and getting it wrong in the ambitious direction is how template projects collapse.

The Audit Trail as the Real Deliverable

Businesses buy approval tooling to go faster. What they end up valuing is the record.

What Odoo captures. Records carry created-by and last-modified-by and when. Tracked fields write changes into the record’s chatter with author and timestamp. State transitions on approval-enabled documents are recorded. Signature completions carry signer, sequence and timestamp. Messages sent from the record stay on the record.

What it does not capture by default. Not every field is tracked — tracking is configured, not automatic. Read access is not logged. Exports are not comprehensively logged. Do not assume the system records everything; establish what is actually tracked for the fields that matter to you, and turn on tracking for the ones that are not.

And the part nobody says. A log is only a control if somebody looks at it. “We will check the audit trail” is not a control; a quarterly review with a named owner is.

Compare this against the paper process it replaces. A scanned signature page of unknown origin, in a shared folder, with no record of who sent it or when, is weaker evidence than a timestamped completion record — which is why the audit conversation usually ends up supporting the project rather than obstructing it.

Benefits You Can Measure

1. Approval cycle time, by document type and by approver. The distribution matters more than the average.
2. Ageing of pending approvals — how many requests are older than two days.
3. Signature turnaround time from dispatch to full execution.
4. Documents outstanding for signature and their age, as a standing report.
5. Value of transactions held in approval at any moment. This is the number that gets management attention.
6. Exceptions to authorisation limits — should be zero once enforced in the system.
7. Re-keying incidents, where a document had to be corrected because it was typed rather than generated.
8. Time spent chasing approvals, which is real work that disappears.
9. Audit findings on authorisation, year over year.

Approval Approach Comparison

Best Practices

1. Write the delegation-of-authority matrix before configuring anything — document type, threshold, approver, deputy.
2. Use the native controls first. Configure double validation and expense routing before considering a build.
3. Set thresholds that produce a manageable volume. A limit so low that a director approves forty items a week produces rubber-stamping, which is worse than no control.
4. Give every approval a deputy or an escalation. Absence must not stop a process.
5. Give approvers context in the request, not just an amount.
6. Make the pending queue visible to the requester. Most chasing exists because the requester cannot see where the request is.
7. Decide signature digitisation by document class, with legal sign-off per class.
8. Generate standard documents from records; do not retype them.
9. Attach executed documents to the record they belong to, and define retention.
10. Turn on field tracking for the fields that matter rather than assuming everything is logged.
11. Review the approval log quarterly with a named owner.
12. Govern Studio-built approval logic like any other customisation — register it, document it, and consider its upgrade surface.

Common Mistakes

• Digitising the signature and leaving the review process alone. The bottleneck moves nowhere.
• Thresholds set too low. Volume produces rubber-stamping, and a rubber stamp is not a control.
• No deputy for any approver. One person’s annual leave becomes a procurement freeze.
• Approval requests with no context. Approvers either ask questions, which adds a round trip, or approve blind.
• Building in Studio what purchase double validation already does. Maintenance cost for no gain.
• Assuming all signatures can go electronic. Some document classes cannot, and finding out at enforcement time is expensive.
• Ignoring stamping and registration obligations. A valid signature on an unstamped instrument can still be unenforceable.
• Executed documents saved to a shared drive instead of the record. You have digitised the signature and kept the filing problem.
• Assuming the audit trail captures everything. Tracking is configured; unconfigured fields are silent.
• Treating the log as a control without reviewing it.
• No paper path. A counterparty who insists on wet ink stops a process with no fallback.
• Rolling out to everything at once. Two document classes done well beat twelve done badly.

An Illustrative Scenario: A Mid-Sized Engineering Company

A composite illustration built from common patterns, not an account of a specific named client.

Consider an engineering company making custom equipment, running Odoo for sales, manufacturing, inventory, purchasing and accounting, with around 140 staff across two plants.

Before

Purchase orders were raised in Odoo and approved by email. The delegation-of-authority policy existed as a two-page document from a previous financial year, and nobody could say with confidence whether it was being followed. Customer contracts were typed in Word from the confirmed quotation, emailed as attachments, printed, signed and returned as phone photographs. HR onboarding involved a folder of forms handed to each new joiner on their first morning.

Two symptoms drove the project. First, procurement lead times included an approval element nobody could quantify, and the planning team had built safety stock around it. Second, the external auditor’s management letter had raised authorisation of purchases as a point in two consecutive years.

What Was Implemented

The delegation-of-authority matrix was rewritten first, as a commercial exercise with the finance director and the operations director — document type, value bands, approver, deputy. That took three working sessions and produced the artefact the rest of the project configured against.

Purchase double validation was then configured against the agreed value bands, with deputies named for every approver. Approvers were given a dashboard view of their pending queue with ageing, and requesters were given visibility of where their request sat, which removed most of the chasing immediately.

Expense approval was moved from email to the native two-stage route, separating manager approval from finance posting.

For customer documents, the standard order acceptance and terms were converted to generated output driven by the sales order, so the values could no longer diverge from the order. Odoo Sign templates were built for the acceptance document, the standard NDA, and the HR onboarding pack. Negotiated contracts were deliberately left outside the template scope and continued to be handled as individual documents — a decision the commercial director initially resisted and later agreed with.

Before switching any class over, the company’s legal adviser was asked to confirm the position for each document type in its jurisdiction. Two categories were kept on paper on that advice, including one where a stamping obligation applied.

Field tracking was enabled on the fields finance and audit cared about, and a quarterly approval review was scheduled with the finance controller as owner.

After Two Quarters

Approval cycle time became visible for the first time, which was itself the most useful outcome — the planning team could finally quantify the internal component of procurement lead time and began removing safety stock that existed solely to absorb it. Pending approvals older than two days fell substantially once the queue and the ageing were visible; the mechanism was not enforcement but embarrassment.

Signature turnaround on the templated document classes reduced markedly. On negotiated contracts it barely changed, which confirmed what the process mapping had predicted: the delay there was internal review and counterparty redlining, not the signature.

The authorisation point in the auditor’s management letter was closed, on the basis that the limits were now enforced by the system and the approval record was on the transaction rather than in a mailbox.

Industry Use Cases

• Manufacturing. Purchase authorisation by value band, supplier agreements, quality sign-off gates, and customer acceptance documents. See manufacturing solutions.
• Trading and distribution. High purchase order volume with tight margins, dealer and supplier agreements, and credit limit enforcement as an approval control. See trading and distribution solutions.
• Logistics. Subcontractor agreements, rate confirmations, delivery acceptance, and driver documentation. See logistics solutions.
• Healthcare. Consent and acknowledgement documents, vendor and equipment agreements, and controls where authorisation trails carry regulatory weight. See healthcare solutions.
• IT and professional services. Statements of work, change orders, NDAs, and contractor onboarding. See IT services ERP.
• Automotive and EV. Dealer agreements, warranty documentation, and parts purchase authorisation. See automobile and EV solutions.

Implementation Tips

1. Write the delegation-of-authority matrix first. Configuration without it encodes a guess.
2. Pull timestamps from twenty real recent examples to find where the delay actually is before you design anything.
3. Configure the native controls before evaluating any build. Most requirements are met there.
4. Pick two document classes for the first Sign rollout — one internal, one external — and get them fully working.
5. Get legal confirmation per document class before switching it over, not after.
6. Name a deputy for every approver at configuration time, not as a later fix.
7. Build the pending-queue view for approvers and the status view for requesters on day one. They remove more delay than the approval mechanism itself.
8. Keep a paper path for counterparties who require it.
9. Register any Studio-built approval logic in your customisation register with its purpose and owner.
10. Schedule the first review at one quarter, with cycle-time data. Techvaria’s Odoo support and maintenance engagements cover approval drift as teams and thresholds change.