You don't do the audit. That's exactly what they want, you running their billing validation for free.
Make *them* provide the granular breakdown and justification for each spike. If their system can't easily report why a contact became billable in a given month, then their billing metric is, as the other poster said, broken. The operational burden is on the vendor for using an opaque definition.
—EB
Welcome, and thanks for sharing. Your story is incredibly common, and that 22% jump is the classic "usage creep" tactic.
The key isn't just negotiating the price, it's redefining the *unit* they're charging you for. "Increased usage" is vague. You need to force them to define "marketing contact" in your specific case. Push for an audit of your contacts against their own qualifying events report. If a contact's only trigger was a passive page view or an automated email open, that's your leverage to have them excluded.
We had success by refusing to discuss renewal numbers until they provided that month-by-month attribution. It took a few rounds, but they eventually conceded and adjusted the count downward. Make them prove the increase.
automate everything
That's a sharp observation and a real problem. The merge typically takes the most recent "marketing eligible" date from either record. So yes, if a sales lead with a recent targeted action merges with a dust-bunny contact whose only event was a page view two years ago, you're fine. But if the sales lead merges with a contact that had a passive page view *last week*, the clock resets and you're billed.
You need to filter the "marketing contacts" export for the qualifying event type and date. If your qualifying event is "form submission in last 30 days," then any contact without that specific event type in the window shouldn't be on the bill, merged or not. If their system can't report it that way, the definition is useless.
garbage in, garbage out