Approval sign-off in Odoo is mostly invisible. A purchase order goes from draft to purchase, an invoice gets posted, a delivery gets done — but the who, the when, and the visible authorising mark that auditors, vendors and warehouse receivers expect all live outside the record, in scanned PDFs, email threads and paper folders. Teams end up printing an Odoo document, signing it by hand, re-scanning it, and attaching it back — a loop that defeats the point of running the ERP. Odoo core gives you the approval state machine and the audit mail.thread log, but it does not capture a graphical signature on purchase.order, account.move or stock.picking, and it does not print that signature on the QWeb report. On Community the gap is total; even where sign widgets exist elsewhere, they are not wired into procurement, billing and warehouse documents the way a paper-driven or compliance-driven process needs.

This is what we build to order. We add a signature capture surface — an OWL-based signature pad plus an optional "signed by" user binding — onto the forms you actually route for approval: purchase.order, account.move (both vendor bills and customer invoices), and stock.picking (deliveries and receipts). Under the hood the signature is stored as a binary field on the target model with companion signed_by (res.users/res.partner), signed_on (Datetime), and computed signature_state fields driven by @api.depends, so the record itself carries a first-class, queryable signing state instead of a loose attachment. Access is enforced through ir.model.access.csv plus record rules so that only the roles you nominate — a purchase manager, a finance approver, a warehouse lead — can affix or clear a signature, and an automated action can require the signature before the document is allowed to leave draft. The captured image is rendered into the QWeb PDF reports (purchase.report_purchaseorder, account.report_invoice, stock.report_deliveryslip, or bespoke report templates) so the document you email or hand to a counterparty shows the signature, the signer's name and the timestamp exactly where your process expects them.

Because it is delivered as a proper module, everything is configurable to your reality: which documents require signatures, whether a second counter-signature is needed, whether the signature blocks state transitions or is advisory, and how it appears on the printout. We can bind signatures to your existing approval hierarchy, surface them in list and kanban views for at-a-glance status, expose them over the XML-RPC/JSON-RPC API so an external portal or mobile app can post a signature back, and fire an automated action or activity when a document is still awaiting sign-off. The module ships with a clean __manifest__.py declaring dependencies on purchase, account and stock, versioned for Odoo 17.0, 18.0 or 19.0, and respects Community vs Enterprise boundaries — we do not assume paid apps you may not have, and we tell you upfront if a request needs an Enterprise-only dependency.

Delivery is build-to-order: after a short scoping call we confirm exactly which documents, roles, report layouts and approval rules are in play, then build against your Odoo version, deliver on a staging database for UAT with a documented rollback, and only then install to production. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $299 (indicative, single-company base scope); additional signed document types, multi-company signing rules, custom QWeb report redesigns, and integration with an external signing or approval portal increase the quoted scope. You receive a firm fixed quote after the scoping call — never an open-ended bill.