An e-signature is very good at proving one thing: a specific person clicked "Sign" at a specific time. It says nothing about whether the company named at the top of the contract actually exists, is still active, or is spelled the way the law knows it.

For a residential lease with an individual, that's less of a concern. For a commercial lease, where the tenant is a company, it matters a lot. A contract with the wrong legal name, or with a company whose registration has expired, is the kind of problem nobody notices until the day someone needs to rely on that contract.

In Kate PMS, our property management system, contract signing includes a verification step against Commercial Registration (CR) records. Below is how I think about designing a step like this: the principles, not the internals.

Why verify at all?

When a company signs a lease, a few things need to be true:

• The company is real and registered.
• Its registration is valid on the day of signing, not expired.
• The name and CR number on the contract match the official record exactly.

Without a check, all of these depend on someone reading a scanned document carefully, every time, under deadline pressure. People are good at many things. Spotting that "Trading" became "Trade" in a company name on the fortieth contract of the week isn't one of them.

So the system does the boring comparison, and people handle the judgement calls.

Where it sits in the signing flow

The most important design decision is making verification a gate, not a checkbox. A contract for a company tenant moves through clear states, and it can't reach "ready to sign" without passing verification:

1. Draft: staff prepare the contract with the company's details and CR number.
2. Verification: the system compares those details with the Commercial Registration record.
3. Verified or needs review: a clean match moves forward; anything else stops here with a clear reason.
4. Sent for signing: only verified contracts go out for e-signature.
5. Signed: the signed document and the verification result are stored together.

Modelling this as states, instead of a boolean like is_verified, pays off quickly. You can see where every contract is, the UI can only show actions that make sense in the current state, and there's no back door where a contract skips a step because someone called the wrong method.

What gets compared

The comparison focuses on the details that make a contract legally meaningful: the CR number, the registered company name and the validity of the registration on the signing date.

Comparing names sounds simple until you try it. The same company can appear with different spacing, punctuation, letter case, or abbreviations of its legal form. So before comparing, both sides are normalised to remove formatting noise.

The firm line to draw: normalisation removes noise, it never guesses. There is no "92% similar, close enough". If two names still differ after cleaning up spacing and punctuation, a human looks at it. Fuzzy matching is great for search boxes. It's the wrong tool for deciding who a legal contract is with.

Handling mismatches

Most of the design work goes here, because the happy path is easy. Every failure needs a clear outcome and a clear next step for staff:

That last row matters more than it looks. When a check can't complete, it's tempting to let the contract through so work isn't blocked. That turns your safety check into a check that only works on good days. A failed check is "not verified", full stop.

Overrides, with a paper trail

Real life is messy, and sometimes a mismatch has a legitimate explanation that staff can confirm another way. So the system allows an override, but only for roles that are permitted to make that call (Kate PMS uses role-based access throughout), and only with a written reason.

Every verification attempt is recorded: what was checked, when, the result, and if someone overrode it, who and why. When a question comes up months later, the answer is in the contract's history rather than in someone's memory.

Timing: verify close to signing

A registration can be valid when a contract is drafted and expired by the time it's signed, especially if negotiations take a while. So verification happens as the contract moves towards signing, and a contract that sits too long can be checked again before it goes out.

What I'd tell anyone building something similar

• Make verification a state in the workflow, not a flag someone can forget to check.
• Normalise formatting, never guess. Anything that isn't an exact match after cleanup goes to a person.
• Fail closed. An error, a timeout or a missing record is a hold, not a pass.
• Allow overrides, but make them deliberate: right role, written reason, permanent record.
• Show staff why something is held. "Verification failed" creates support tickets; "Registered name differs: see both versions" gets the problem fixed.

Software that handles contracts is mostly about trust: the landlord trusting the tenant is who they say, and staff trusting the system not to wave things through. A verification step that is strict, transparent and well recorded is a big part of earning that.

If you've built verification into a business workflow, how did you handle the cases that were "almost" a match?