SCREDIT vs. a certificate folder and a tracker

Almost every credit department that handles exemption certificates arrived at the same setup without ever choosing it: the certificates themselves live in a shared drive, and a spreadsheet somewhere lists which customer has one and when it runs out. Nobody designed this. It accumulated, and for a while it works.

It works because the two halves are maintained by the same person, who remembers which is authoritative when they disagree. The failure mode is not that the folder is messy. It is that the folder and the tracker are two records of one fact, and nothing keeps them in step — a certificate can be replaced without the date being updated, and a date can lapse in the tracker while a perfectly valid certificate sits in the folder.

This page compares that setup with holding the certificate, the jurisdictions it names and its expiry as one record on the credit file. It is not a comparison against being disorganised; it is a comparison against a process that is working, and the specific place where it stops.

Dimension	Shared drive + tracker spreadsheet	SCREDIT
Where the certificate lives	A shared drive, named by whatever convention the person filing it used. Findable if you know the customer's legal name, harder if the certificate was filed under a trading name or a branch.	On the credit file for that customer, in the same document platform as the rest of their credit record, with role-based access and a record of who opened it.
Where the expiry date lives	A column in a separate spreadsheet, typed in by hand when the certificate was filed.	On the certificate record itself. There is one date, and it is attached to the document it describes.
Whether the two agree	Only if someone kept them in step. A replaced certificate with an un-updated row, or a row for a certificate nobody can find, are both common and neither announces itself.	Not a question that arises. The document and its expiry are one record, so they cannot disagree.
Who notices an expiry	Whoever opens the tracker and sorts by date, if they remember to. Most teams discover a lapse when an invoice is raised without tax and someone queries it.	An approaching expiry surfaces on its own rather than waiting to be looked for.
Collecting it in the first place	An email, then a reminder, then a call. The request lives in someone's sent items and its status is whatever they recall.	Requested against the credit file with the rest of the onboarding documents, and the customer can see what is outstanding in the portal rather than asking.
A customer exempt in eleven states	Eleven certificates, potentially eleven rows, and no reliable way to see the customer's overall position from either the folder or the tracker.	The certificate and the jurisdictions it names are one record with one expiry to monitor. Where a state requires its own form instead, that is collected alongside as a separate record.
The wrong form arrives	Discovered whenever someone next looks at it, which may be at audit. The customer has moved on and re-asking is now an awkward conversation.	Checked against the credit file when it arrives, so the re-request happens while the customer is still in an onboarding conversation.
The exempt flag in your ERP	Set once at account setup. Nothing connects it to whether the certificate behind it is still valid, so the flag can outlive the paper by years.	The ERP still owns the flag and the invoice. What changes is that there is now an authoritative answer to whether a current certificate exists to support it.
Proving it later	Assemble the folder, the tracker and someone's memory into a defensible account of what you held and when.	The certificate, its jurisdictions, its expiry and the record of who accessed it are already together on the credit file.
When the person who maintains it leaves	The tracker survives; the knowledge of which entries are trustworthy does not. Most teams rebuild rather than inherit.	The process is in the system rather than in the person, so a handover is an access change.

The gap is between the file and the date

The strongest argument for a certificate system is not storage. Shared drives are good at storage, and a well-run folder is genuinely better than a badly-run system. The argument is that a certificate is not a document — it is a document plus a validity period plus a set of jurisdictions it covers, and a folder can only hold the first of those three.

So the other two get written down somewhere else, and from that moment the team is maintaining a join by hand. Every join maintained by hand drifts. It drifts slowly, invisibly, and in the direction that costs money: a lapsed certificate looks exactly like a valid one until someone checks, and the invoice that went out untaxed in the meantime has already gone out.

What a folder is still good at

Retrieval, if you know what you are looking for. Familiarity, because everyone already has one. And no procurement conversation, which is not nothing.

The point at which it stops being adequate is not a number of certificates. It is the first time two people need to answer the same question about the same customer and reach different answers — which usually happens well before anyone thinks the volume justifies a system.

Frequently asked questions

Does SCREDIT tell us whether a customer is actually exempt?

No, and it should not. Whether an exemption applies to a given customer in a given state is a tax question for your tax advisers or the state revenue department. SCREDIT handles the operational side: collecting the certificate, holding it against the credit file with the jurisdictions it names, monitoring its expiry, and making it retrievable. The judgement stays with the people qualified to make it.

We already have a tax engine. Does this overlap?

They sit at different points. A tax engine determines what to charge at the moment of invoicing. The question here is upstream of that: whether you hold a current, valid certificate for the customer you are about to invoice, and whether anyone will notice when it expires. Teams with a tax engine still generally chase certificates by email and track expiry in a spreadsheet.

What happens to the certificates we already hold?

They come across as the current record and become the starting point. You will not retroactively acquire the provenance of a certificate filed four years ago, but you stop adding to a pile whose validity nobody can vouch for, and the first expiry cycle replaces inherited paper with a record that has a date attached to it.

Is a blanket certificate not enough to make this a non-problem?

A blanket certificate removes the per-order burden, which is real relief, but it does not remove the expiry question — several states put a validity period on blanket certificates, and a customer's circumstances can change within it. It reduces the volume of the problem rather than the shape of it.

How is this different from your spreadsheets comparison?

That page is about running credit management on spreadsheets generally: applications, decisions, exposure, collections. This one is narrower and more specific, because certificate handling has a failure mode of its own — two records of one fact, maintained by hand, where the drift between them is silent.

See SCREDIT on your own workflows.

A 30-minute walkthrough with the team that built it — using scenarios from your credit operation, not canned demo data.

Request a demo Contact sales