Most university labs have a purchasing policy. Very few have a purchasing policy that actually gets followed.
The gap isn't intentional — no one sets out to ignore policy. It's structural. A PDF document that describes how purchasing is supposed to work gets circulated, acknowledged, and promptly forgotten when a researcher needs reagents by Friday. An email approval chain that made sense when the lab had five people breaks down at fifteen. A grant account restriction that the PI knows about gets missed by the postdoc placing the order because no one told them.
By the time the compliance problem surfaces — in an audit, in a grant report, in an unexpected account overdraft — months of non-compliant purchasing has already happened. At that point, the options range from inconvenient to expensive.
The solution isn't a better policy document. It's enforcement built into the workflow.
Why Compliance Problems Happen at Approval Time
The standard mental model of purchasing compliance is: purchasing happens, then compliance is checked. Auditors review what was bought, against what rules apply, and flag violations after the fact.
This model is expensive and ineffective. By the time an audit catches a problem, the money has been spent, the grant period may have closed, and correcting the record requires documentation that may not exist anymore. The cost of retroactive compliance — in staff time, potential disallowances, and audit risk — is far higher than the cost of preventing the problem.
The right model is: compliance is checked before purchasing happens. The policy is enforced at the approval step, when there's still an opportunity to redirect the purchase, change the account, or require additional authorization.
This sounds obvious. It's surprisingly rare in practice, because most compliance tools are designed for reviewers (auditors, grant managers, finance staff) rather than for the people doing the approving. A PI approving a purchase request wants to know: is this reasonable? Is it within budget? Does it fit what we're working on? They're not cross-referencing the NIH grants policy manual.
The answer is to put the relevant policy information in front of the approver automatically — not as a checklist to work through, but as a flag when something needs attention.
The labs that fare best in audits aren't the ones with the most thorough policy documents. They're the ones where the policy is so embedded in the workflow that following it is the path of least resistance.
This is the principle Ixion is built around. Every approval rule a lab defines runs at the moment of request — surfacing the relevant grant restriction, threshold, or account limit to the approver before the order is placed, not after. Compliance becomes a property of the workflow, not a separate effort.