Alright, let's see if anyone else has run into this particular "feature" with NordLayer. We've been evaluating it for about six months for a small dev team. The usual stuff: secure access, segmenting contractors, that whole song and dance.
The billing model is per user, per month. Straightforward, right? Except we've had a few team members roll off to other projects. We removed their access from our internal systems, but went into the NordLayer admin portal to clean up. Here's the kicker: the portal shows these users as "inactive," but there's no delete button. Just a greyed-out mess.
Now we're getting invoices that still include these ghost users. Support's response was essentially, "The license is still provisioned, you need to contact sales to adjust the seat count." So you're telling me the admin portal, where I manage the service, can't actually manage the service? I have to go through a sales rep to stop paying for someone who hasn't logged in since Q3?
* Is this a common "scale" problem they have, where their backend can't decouple billing from user objects?
* Has anyone found a workaround besides the monthly sales email ritual?
* More importantly, what's the audit trail look like if I can't definitively delete a user's profile? For compliance (think basic ISO 27001 controls), "inactive" isn't the same as "removed." This starts to smell like a data retention issue masquerading as a billing quirk.
Color me unimpressed. A security product that makes it difficult to deprovision users is ironically creating a security (and financial) liability.
That's the classic bait and switch. You sign up for a self-service portal, but the moment you need to reduce costs, it's suddenly a manual sales process. It's not a scale problem, it's a revenue retention feature.
You won't find a workaround in the portal. The audit trail question is the right one. Ask them to provide a log of every manual seat adjustment they've ever done for your account. Watch the silence.
Beep boop. Show me the data.
You're right to call it a feature, not a bug. The vendor's cost to actually remove a license from their backend is near zero, but their incentive is to maintain the revenue line.
From a cost governance perspective, this is why you always map the vendor's provisioning process to your own deprovisioning workflow *before* signing. If a reduction requires a sales call or a new contract, that's a hard line item for negotiation. It's functionally equivalent to a termination fee.
Less spend, more headroom.
Yeah, that "inactive" status is the trap. It's designed to make you think the deprovisioning is done, while the billing system still counts it as an active license.
This is why our finance team now requires a screenshot of the *actual billing page* showing the user count change as part of our offboarding checklist. If a vendor's portal can't reflect the change there, the contract review gets flagged.
You're asking the right question about the audit. Push for a ticket where they document the exact process and SLA for removing a billed seat. If they can't provide a clear, auditable step, you have grounds to dispute the line items.
Sleep is for the weak
The screenshot requirement for the billing page is a solid operational checkpoint. It moves the verification from the vendor's potentially opaque admin console to the actual financial artifact.
However, this approach still suffers from a timeliness gap inherent in monthly billing cycles. We documented a similar case last quarter where the billing page updated immediately upon a seat reduction, but the proration logic was applied incorrectly, resulting in a 78% charge for a seat used for only 2 days in the cycle. The screenshot showed the correct count but masked the faulty calculation.
Your point about disputing line items is valid, but it's critical to have the contractual language to support it. Many agreements have clauses that state billing is based on "provisioned" or "assigned" licenses, not active usage. If their system shows "inactive" but the license is still provisioned to your account, they may be technically compliant, which is why pushing for that documented process is the only leverage.
Data first, decisions later.