Guardrails That Stop You Receiving More Than You Ordered
A warehouse team scans in a delivery. The packing slip says 120 units, the purchase order said 100, and Odoo lets the extra 20 through without so much as a warning. Weeks later, finance is trying to work out why landed cost doesn't match the purchase order, and nobody remembers the delivery that ran over. This is one of the quieter ways an ERP loses accuracy: not through a dramatic failure, but through a control that was never turned on.
The setting nobody notices until it bites
Odoo's purchase settings let a team cap receiving at the ordered quantity, allow it to run over within a tolerance, or leave it wide open. Many implementations leave the door open, because at go-live nobody wants to be the reason a delivery gets turned away at the dock. The setting quietly stays permissive long after go-live, and the business assumes stock quantities and purchase order quantities are locked together when they aren't.
Why "just this once" becomes the default
The usual story: a supplier ships a slightly larger batch to save on a second shipment, or a warehouse worker doesn't want to hold up a truck over a small overage, so the extra units get received anyway. The first time it happens, someone makes an exception. After a few exceptions, the exception is the process, and the tolerance setting that was meant to catch genuine errors gets disabled because it keeps "getting in the way." What's left is a receiving process with no ceiling, where whatever quantity a supplier sends becomes the quantity that lands in stock and in cost.
Turning the guardrail back into a guardrail
The fix isn't a strict rule that rejects every truck at the first sign of a mismatch. It's a tolerance that reflects reality: a small percentage over is fine and logged automatically, anything beyond that stops and asks a human to confirm before it posts to stock and cost. That single decision point is what most teams are missing. It turns an over-receipt from a silent accounting drift into a visible exception someone actually looks at, on purpose, instead of by default.
Our take
Over-receipt control is a small setting with an outsized effect on whether stock and cost numbers can be trusted. Majorbird treats this kind of guardrail as part of baseline Odoo configuration, not an advanced add-on, because the cost of leaving it off compounds quietly for months before anyone notices. If a receiving process has quietly grown a habit of "just this once," it's worth checking what's actually enforced versus what's assumed. Talk it through with the Majorbird team.