A certificate that was valid when you filed it is not evidence of anything in particular three years later. That is the entire subject of this guide, and it is the part of certificate handling that most reliably goes wrong, because nothing announces it.
A lapsed certificate looks exactly like a current one. It sits in the same folder, under the same customer name, in the same format. The account keeps invoicing untaxed because the flag that says to do so was set once and nothing has contradicted it. The discovery event, when it comes, is usually an audit or a query about an invoice — both well after the exposure accrued.
The fix is not vigilance. It is a small amount of structure that means nobody has to be vigilant.
"Valid until revoked" is not "never review"
Certificates fall into broad patterns: some carry a stated expiry, some remain valid until revoked or until circumstances change, and some depend on continued activity on the account. The specific rule depends on the state and the certificate type, and it is worth knowing for each state you sell into rather than generalising.
The trap is the middle category. A certificate with no printed expiry date reads as permanent, and teams file it accordingly. But the thing being asserted is the customer's status, and a customer's status can change without anyone informing you — a business is sold, a resale operation stops reselling, a registration lapses. The document does not expire; the truth it asserts can.
So a certificate without a stated expiry is not one that needs no review. It is one whose review date you have to set yourself, which is a different and slightly harder problem than the ones that come with a date printed on them.
The three dates that matter
Most trackers record one date, and it is usually the wrong one on its own. Three are worth holding, and they answer different questions.
- The date the certificate was issued or signed — which tells you how old the assertion is, and is the only one always available
- The stated expiry, where the certificate or the state provides one — the hard deadline, and the easy case
- Your own review date — which you set for every certificate, including the ones with no stated expiry, and which is the date that actually drives work
Renewal is a relationship task, not an admin task
A renewal request that arrives cold, addressed to whoever last touched the account, asking for a replacement of a document nobody remembers providing, performs about as badly as a first request made at the wrong moment. It is the same failure with an older relationship attached.
Renewals go better when they are predictable and when they reach the person who handled it last time. Contacts move on, so the practical version is to re-confirm the tax contact as part of the renewal rather than assuming the one on file is still correct — which is also the cheapest moment to discover they are not.
There is a second-order benefit worth noticing: a renewal cycle is a recurring, low-stakes reason to talk to a customer's finance function. Teams that run one tend to hear about changes at the customer earlier than teams that do not.
What to do when one lapses
Two questions arise, and they are separable. The first is what happens to sales already invoiced untaxed during the gap; that is a tax question, it depends on the state and the circumstances, and it belongs with your tax advisor rather than with a vendor's guide.
The second is operational and is yours: stop the gap widening. In most teams that means the account reverts to being charged tax until a current certificate is on file — which resolves the forward exposure immediately and, as with the initial request, tends to produce the document quickly.
What is worth avoiding is the middle position: knowing a certificate has lapsed, continuing to invoice untaxed while the renewal is chased, and treating that as a temporary state. Temporary states of this kind are measured in quarters.
The calendar that survives a resignation
Almost every team that handles this well has the same underlying arrangement, whatever the tooling: the review date lives with the certificate rather than in a separate list, and something surfaces it without being asked.
The failure mode of the two-artefact approach — certificates in a folder, dates in a spreadsheet — is not disorganisation. It is that the two drift, silently, in the direction that costs money, and that the knowledge of which entries are trustworthy lives in one person. When that person is unavailable, the tracker does not become wrong; it becomes unverifiable, which is worse, because it still looks authoritative.
The test to apply to your own process is not how tidy it is. It is what a colleague would be able to establish about a given customer's certificate position, unaided, on a Tuesday morning while you were away.
Where to check the rules yourself
Nothing here is tax advice, and the rules described in general terms vary by state and change over time. Work from the authorities rather than from summaries, including this one.
For anything consequential — a new state, an unusual exemption basis, a customer whose situation does not fit the pattern — the answer comes from your tax advisor or the state directly.
- The revenue department of each state you sell into, which publishes its own forms, validity periods and acceptance rules
- The Streamlined Sales Tax Governing Board, for the SSUTA certificate, its member states and the exemption reason codes it defines
- The Multistate Tax Commission, for the Uniform Sales & Use Tax Exemption Certificate and the conditions individual states attach to accepting it
- Your own tax function or external advisor, for anything that determines whether a transaction is actually exempt
About the author
SGUTTI · Founder, EFILOS
SGUTTI is the founder of EFILOS and the architect of SCREDIT, the trade-credit operating platform. He writes about credit operations, financial statement analysis, and receivables management based on the workflows SCREDIT is built around.
Connect on LinkedIn