How do I get our sales team to stop expensing fancy dinners as 'client meetings' without proof?

You can absolutely require fields in Expensify before submission, which is the first technical gate you need. Set up a custom policy with required fields for client company, attendee names, and business purpose. Submissions missing these fields won't even get to you. This turns it from a personal denial into a system requirement.

From an accounting and audit standpoint, a receipt with only a total is insufficient. You need itemized details to substantiate the business nature of the expense. A policy requiring this isn't bureaucratic, it's a basic financial control. Frame it as a protective measure for them as much as for the company; without proper documentation, the IRS could disallow the deduction and create a tax liability.

The pushback about speed is a trade-off. The latency you introduce with proper validation saves orders of magnitude more time later during tax prep or an audit. Automate the validation at the point of submission so the slowdown is upfront and systematic, not a surprise during reimbursement.

The "it's slowing me down" pushback is pure noise. Their speed is irrelevant if you get audited.

Set the custom policy in Expensify, but that's just the start. Tie it to the per diem. No client/project name? It's a personal meal, and the reimbursement rate drops to the standard meal allowance for the city. That's what, $30-$40 for dinner? Not $200 at a steakhouse. Suddenly the paperwork is worth their time.

A policy without a direct cost consequence is just a suggestion.

The technical setup in Expensify is the easy part, as others have said. The real issue is that you're framing this as an accounting problem when it's actually a trust and authority problem.

If you're new and they're pushing back, your policy won't stick without explicit, visible backing from whoever manages the sales team. A system rejection is just an obstacle they'll complain about upwards. You need the sales VP to send the memo saying "compliance is part of your quota," otherwise you're just the bottleneck they said you'd be.

And while an itemized receipt is good, it's still just a piece of paper. I've seen "client dinners" with four steaks and eight cocktails. The agenda question is what you should really care about. If they can't articulate the business purpose beyond "building the relationship," then it's just a fancy meal.

You've identified the core issue precisely. The technical enforcement is necessary, but it's merely a tool that fails if the organizational culture doesn't support it.

The phrase "trust and authority problem" is particularly apt. A new policy from finance or operations, without the sales leader's vocal endorsement, will be interpreted as a lack of trust in the team's judgment. That creates immediate resistance. The sales VP needs to communicate that proper documentation is a non-negotiable component of the sales role, not an administrative hurdle. It protects the company, yes, but it also protects the salesperson's own commission if an audit were to claw back deductions.

Your point about the agenda moves the discussion from pure compliance to value assessment. Asking "what was the business outcome?" shifts the burden from the accountant playing detective to the salesperson demonstrating the meal's strategic purpose. This often reveals whether the expense was an investment or merely an indulgence.

Agreed on the sales VP's role. But I'd also track the data.

Implement the required fields, then pull a monthly report: salesperson, total "client meeting" meal spend, deal size from associated opportunities. If someone's consistently showing high dinner expenses with zero linked pipeline movement, that's your case for the VP.

Data beats arguments. It's not about trust, it's about measurable return.

Absolutely not unreasonable, that's basic substantiation. The core question is how you position it.

You're right to focus on setting the fields as required in Expensify. That's your first technical control. Go into the policy settings and make Client Name (or better, a dropdown linked to your CRM), Attendees, and Business Purpose mandatory fields. Submissions will bounce back to them, not you, which depersonalizes it.

But user1586's point about trust is critical here. If you just flip the switch, you *will* be seen as the bottleneck. Before you enable anything, you need a brief, joint announcement. The message should come from both Finance *and* the Sales VP, framing it as a new standard operating procedure to protect everyone from audit risk, not as a response to abuse. The sales leader needs to say, "This is part of the job now."

Your instinct about the brief agenda is the smarter long-term play. Asking for the client name is compliance; asking for the business purpose or outcome shifts the conversation to value. It forces a moment of reflection. Was it a pitch, a contract renewal, a troubleshooting session? That detail is often more revealing than the receipt itself.

You're right about the authority piece. A system mandate without leadership buy-in is just a friction point they'll escalate around.

The agenda point is interesting. We operationalized that by requiring the salesperson to link the expense to a specific opportunity ID in Salesforce. The "business purpose" field isn't free text, it's a picklist tied to our sales stages: "Initial scoping," "Technical validation," "Contract negotiation," etc. It forces a direct line between the spend and a measurable stage of a deal. No open opportunity, no "client meeting" category.

This turns the agenda from a story into a data point. It's harder to argue with a dropdown.

You're spot on about depersonalizing it with system requirements, but that joint announcement is crucial. We tried flipping the switch first and got immediate backlash until the sales director re-framed it as "this is how we protect your commissions from being clawed back in an audit."

The dropdown for business purpose linked to sales stages is brilliant. We did something similar, but we also added a quick "next step" field. It forces the reflection you mentioned. If the purpose was "contract negotiation," the next step better be something like "send revised SOW" and not just "follow up." It connects the spend to forward motion.

You're right to focus on the technical gate in Expensify. Making those fields required pre-submission is the correct first step, and it removes you as the personal gatekeeper.

But I'd go a step further on the data structure. Instead of just a free-text "client name" field, integrate it with your CRM if you have one. The field should be a dropdown pulling from active accounts or opportunities. This prevents typos and fictional entries, and it creates the audit trail you need. If a deal isn't in the system, the expense can't be classified as a client meeting - it forces the data hygiene upstream.

The pushback on speed is a false economy. The few minutes it takes to select from a dropdown is negligible compared to the hours required to reconstruct records during an audit. Frame the system setup as automation for *their* benefit, reducing back-and-forth emails.

> make it required *before* submission

That's the only way. Set the policy so the form won't submit without the fields. They'll yell, then they'll fill it out.

But don't stop there. Their pushback about speed is nonsense. A five-minute task versus an audit that takes weeks. Make the fields a dropdown linked to your CRM if you have one. No active account/opportunity, no "client meeting" category. Forces the record-keeping upstream.

And ignore any talk of being a bottleneck. Your job is to keep the company's records clean, not to be their friend. If they want a rubber stamp, they can go elsewhere.

I agree that making fields required pre-submission is the only effective technical control. However, your "ignore the bottleneck talk" stance is architecturally unsound in a corporate environment.

You're treating the system as an isolated enforcement point, but it's a node in a larger human workflow. If you configure the policy without addressing the social graph, you create a single point of failure - yourself. The complaints won't stop at yelling; they'll route around you via their manager, creating political debt that undermines your mandate.

The correct design is to treat the policy enforcement as a backend service, with the sales leadership providing the frontend API contract. Let them own the communication and handle the first-line support queries. Your role is to ensure the system logs everything and provides the audit reports, not to be the public-facing firewall.

The per diem linkage is an effective behavioral lever, but I'd argue it introduces administrative overhead you might not want. Now you're managing two separate reimbursement workflows - one for substantiated client meals and another for personal meals at a different rate. That creates its own audit trail complexity.

A cleaner method is to maintain the single policy but enforce a hard stop: no required fields, no submission. The expense report simply doesn't move to approval. The cost consequence isn't a reduced rate, it's a non-existent reimbursement. They either comply or they don't get paid, which is a more direct incentive than a partial payment.

The real issue is whether your finance system can handle splitting a single report into two reimbursement tiers automatically. If it's a manual adjustment, you've traded one problem for another.

You're not the bottleneck. Your auditors will be if you don't get this under control.

> Is it unreasonable to ask for the client name and a brief agenda?
No, it's the legal minimum for tax deductibility in most places.

Set the fields in Expensify as required *before* the report can be submitted. Do not allow manual overrides. Receipts must have attendees written on them before upload. The pushback is just noise. The system either accepts a complete report or it doesn't. There's no discussion.

If you're worried about being the bad guy, get the Sales VP to send the announcement that this is a new company-wide requirement effective immediately. Your job is to configure the system to enforce it. Their job is to sell it.

I'm glad you're asking about this early on. You've gotten excellent technical advice here about setting up required fields, and I agree that's the foundation.

One thing I'd add, since you mentioned you're new and worried about being seen as the bottleneck, is to build a clear "help" path. When you enable the new required fields, also create a simple one-page FAQ. Include things like "What if I can't select a client from the CRM dropdown?" with a link to the process for adding a new prospect. Anticipate their roadblocks and solve them proactively. This turns you from a gatekeeper into an enabler.

The pushback about speed usually fades when the system is simple and they see their reimbursements happen faster because there's no back-and-forth. Good luck with the rollout