Hi everyone. Long-time lurker, first-time poster. I’m in a procurement role at a mid-sized professional services firm, and I’ve spent the better part of the last two years evaluating and implementing spend management tools. We landed on Spendesk about 18 months ago, and while the out-of-the-box policy controls were good, we were still seeing policy violations slip through – mostly around project codes, client billable status, and specific budget owner approvals. It was creating a monthly reconciliation nightmare for our finance team.
Our goal was 100% policy compliance at the point of spend, not just during the monthly close. We realized the default fields (category, amount, merchant) weren't capturing the unique rules of our business. The breakthrough for us was a very deliberate, step-by-step rollout of custom fields. I wanted to share our process because it wasn't just about turning on the feature; it was about change management and tying it directly to our approval workflows.
Here’s exactly what we did, in order:
* **Phase 1: Audit & Categorize Violations.** For one month, finance flagged every single policy violation, even minor ones. We sorted them into two buckets: "Missing Information" (e.g., no project code) and "Rule Breaks" (e.g., non-billable client dinner). The "Missing Information" bucket was 80% of our problem.
* **Phase 2: Design with Stakeholders.** We didn't design the custom fields in a vacuum. We mapped each common violation to a required field.
* Violation: "Expense charged to inactive project." -> **Custom Field:** "Project Code" (Dropdown, synced nightly from our PSA).
* Violation: "Client entertainment not pre-approved by Partner." -> **Custom Field:** "Client Billable?" (Yes/No toggle). This then triggered a separate mandatory "Approver" field for "No" answers, routing to the specific Partner.
* Violation: "Team lunch over per-person budget." -> **Custom Field:** "Number of Attendees" (Number field). This allowed us to set a formula in the policy: `Amount / Attendees` must be less than £35.
* **Phase 3: The Phased Rollout.** This was critical. We enabled one new mandatory custom field per two-week pay cycle, starting with the Project Code.
1. Week 1: Communication. We sent a short Loom video showing *how* to fill the field and, more importantly, *why* (i.e., "This ensures your expense is charged correctly and you get reimbursed faster").
2. Week 2: Soft Launch. The field was visible but optional. We monitored and gave gentle nudges.
3. Week 3: Mandatory. The field became required for submission. Support was on high alert for the first 48 hours.
4. Week 4: Consolidate. Then we moved to the next field.
* **Phase 4: Integration into Approval Rules.** The final piece was making the custom fields part of the automatic approval logic. An expense with "Client Billable? = No" now *must* go to the pre-defined Partner approver before it even reaches finance. The system blocks submission if that field isn't filled correctly. This moved the compliance burden from finance (chasing people) to the employee at the moment of creation.
The result? After six months, we hit consistent 100% policy compliance on submitted expenses. The real TCO improvement wasn't just in saved finance time (which is about 15 hours a month), but in the elimination of rework, delayed client billing, and the sheer mental overhead of policing receipts. The key was using custom fields not as passive data collectors, but as active gatekeepers for our specific business rules. I'm curious if others have taken a similar approach with custom fields in their expense tools, or if you've found other levers to pull for policy adherence.
That first audit phase is absolutely critical, and I'm glad you started there. Too many teams jump straight to configuring fields based on what they *think* is the problem, not the actual data.
We did something similar, but we added a third bucket to your two: "Violations due to unclear policy." Sometimes the finance team was flagging something that the employee genuinely didn't know was a rule. That distinction helped us later when we designed the field requirements and the help text - it showed us where we needed more education, not just more enforcement.
How did you handle categorizing violations that were really on the edge, where even your approvers were split on whether it was truly out of policy?
buyer beware, but buy smart
Excellent point on the third bucket. We actually saw that "unclear policy" category merge with our "edge cases" over time. For those split decisions, we adopted a simple rule: if at least one approver in the chain flagged it, it went into the audit log for review *before* the spend was approved.
This gave us a dataset of contested transactions. We'd review them weekly with finance and department heads. Many of those debates revealed that our policy document was interpreting a *principle*, but we hadn't defined the operational rule a field could enforce. The "edge case" wasn't an exception - it was a missing requirement.
For example, our policy said "client gifts over £50 require director sign-off." But we hadn't defined "client gift." Was a team lunch a gift? We created a custom field "Client Entertainment Reason" with specific dropdown options. The edge case gave us the data to build the rule.
Every dollar counts.
Exactly. The weekly review of those contested items is the secret. Most places just create a rule from the loudest person in the room. You let the data argue for you.
But that's the moment where you find out if your tool can actually keep up. Spendesk's custom fields are fine for simple dropdowns. Wait until you need a conditional field that only appears for certain categories, or cascading logic between budget and project code. That's where their "automation" gets brittle fast.
Your team lunch example is perfect. Every policy is full of those ghosts. Finding them is the real work.
CRM is a necessary evil
That initial audit phase is the most important step most teams skip. They start building fields based on departmental politics or perceived pain, not empirical data. Sorting into just two buckets, though, is risky.
You need a third category: "preventable by system configuration." If a violation was due to an employee forgetting a project code, that's a system fix (make the field required). If it was due to them not knowing the rule, that's a training or policy clarity issue. If it was because the approver misapplied a vague guideline, that's a workflow or field logic problem. Conflating these during your audit will send you down the wrong path, adding complexity where you need simplicity, or adding a field where you actually need a better dropdown.
What was your threshold for "minor" violations? In my experience, those are often the most telling because they reveal habitual workarounds.
Measure twice, cut once.
Ah, the one-month audit. A classic starting point. I'm curious what percentage of your overall monthly transactions those "violations, even minor ones" represented. If it was a small fraction, you were likely just documenting the usual noise. If it was a significant chunk, your underlying policy might have been the problem, not the lack of custom fields.
The real test is whether your categorization logic held up six months later. In my experience, you can sort violations into buckets neatly for a while, but people get clever. They start entering "project codes" that are technically valid but meaningless, just to get past your required field. Did your process account for gaming the system, or just for honest mistakes?
Show me the data