Exception Register — Notary Documentation
Why an exception register is necessary
Property files often receive notarial documents in imperfect condition: a power uses an old passport number, a translation omits a page, a company representative’s authority is unclear, a sale promise identifies the property differently from current registry data, or a notarial sale case has not completed its system step. The wrong response is either to reject everything automatically or to wave the issue through because the paper carries a notary stamp. An exception register creates a controlled middle path: describe the defect precisely, assign an owner, define evidence needed to resolve it and block the affected action until closure.
Write the exception as a factual statement
Avoid vague labels such as “notary problem.” A useful entry says what document was received, its date and issuer, what was expected, what differs, and why the difference matters. For example: “Power of attorney identifies passport A; current seller uses passport B; no identity-link document yet provided.” Or: “Notarial sale promise refers to unit 18; current title candidate is unit 81; no bridge document.” This language lets another reviewer understand the issue without interpreting someone else’s risk score.
Classify by function, not by severity colour
Useful categories include identity mismatch, authority/scope gap, authenticity/verification gap, translation or language gap, formal-shape issue, property-identity mismatch, expiry/deadline issue, superseded document, missing original/certified copy, and incomplete system/registry step. Categories help route the issue to the right person. A severity colour alone does not tell the team what evidence will close the item. One “red” issue may need a new power; another may need a current registry extract; they are operationally different.
Assign one owner and one closure test
Every exception should have a named responsible role and a clear closure condition. If the issue is scope of authority, closure may require a replacement or legal confirmation that the existing power covers the act. If identity differs, closure may require official evidence connecting the identities. If the notarial sale route is incomplete, closure requires proof of the required system and registry completion. “Seller says it is fine” is not a closure test. The evidence must answer the original factual problem.
Preserve both the defective and corrected version
Do not delete the document that triggered the exception. Mark it as superseded or insufficient and preserve the replacement next to it. This shows why the team requested a new document and prevents the old version from re-entering circulation later. If the correction is a notarial amendment, retain the original and amendment as a pair. If it is a translation correction, keep the old translation to document the error but make the validated version the only active working copy.
Control exceptions around powers of attorney
Authority issues deserve special discipline because an invalid or insufficient power can affect the ability to bind the principal. Record whether the power identifies the transaction or property adequately, includes required acts, remains unrecalled, and matches the current principal. For corporate parties, record how corporate representation was checked. If wording is genuinely ambiguous, the safer course is replacement or qualified legal confirmation rather than stretching interpretation to fit the closing schedule.
Control exceptions in notarial real-estate sale workflow
Official TKGM material for notarial real-estate sales describes checks of right-holder status and legal obstacles, system registration, journal number and subsequent land-registry registration. An exception can therefore arise even where the signed paper looks complete—for example, system status is unfinished or registry data cannot be reconciled. The register should distinguish “document signed” from “sale process completed.” If registration is the required endpoint, only evidence of that endpoint closes the issue.
Link unresolved exceptions to payment and signing
Each open exception should identify which actions it blocks. A translation typo in a non-material address line may not block payment, while uncertain seller authority should. A missing registry completion step may block treating ownership as transferred. This link prevents the team from closing an issue administratively while the commercial process continues as if nothing happened. Exceptions should be reviewed before non-refundable payment, signature and final registration checkpoints.
Close with evidence and date
When resolved, record the closure date, who reviewed it, what evidence was added and why that evidence answers the issue. Do not erase the entry. A closed exception is part of the audit trail and can be useful in a future resale or dispute. If an exception is accepted rather than cured, record who had authority to accept it and what residual consequence remains; do not relabel acceptance as verification.
Quality standard
A good register is short enough to use but precise enough to audit. At any time it should answer: what is wrong, where is the source document, who owns the fix, what action is blocked, what evidence is required, and whether the item is open, cured, superseded or explicitly accepted. This structure prevents notarial documentation from becoming a pile of stamped papers with unresolved contradictions hidden inside.