A lease bonus file can contain a signed lease, an approval email, a check image, and a bank statement and still fail a simple audit question: which tract was paid, to which owner, under which authority, and did the funds clear? The documents exist, but the chain does not.
This study design defines a way to measure that chain. It treats evidence completeness as an administrative property of an obligation record, not as a legal conclusion about title, ownership, or payment validity. The design is intended for land operations teams, internal audit, and acquisition due diligence reviewers who need a reproducible test rather than a folder-by-folder impression. It does not determine whether a bonus was legally owed or whether a payee was correctly identified.
Lease Bonus Payment Evidence Completeness Study: Research question and boundary
The primary question is: for a defined population of lease bonus obligations, what proportion contains the required evidence at each of five gates, and what is the age and reason mix of the missing evidence?
The five gates are obligation, payee authority, release, delivery, and clearing. A file is not "complete" because it contains many documents. It is complete for this purpose when each gate has a defined evidence item, a date, a source, and a reviewer acceptance where the procedure requires one.
The unit is one lease, tract, and payee obligation. A lease with three tracts and two payees can produce several units. The study excludes documents that are merely related to the lease but do not prove the payment event, such as a negotiation email or an unfiled draft.
Why this matters operationally
Payment evidence is usually assembled for one of four reasons: an owner asks where the money is, an auditor samples the file, an acquisition buyer requests support, or a dispute arises years later. In each case, the reviewer needs to move from the obligation to the instrument and the bank record without relying on the memory of the person who processed it.
The lease bonus payment proof packet describes the operating packet. This study design tests whether that packet is actually present and usable across a population. The distinction is important: a template can exist while most files omit one or more gates.
Federal tax guidance is relevant to the payee gate because payers commonly request a taxpayer identification number and classification before issuing reportable payments. The IRS Form W-9 page and the Instructions for Form 1099-MISC describe those information-reporting expectations. They do not establish signer authority or ownership, which remain separate review questions.
Definitions and evidence states
Define each gate before inspecting files. A useful evidence state set is: present and accepted, present but unreviewed, referenced but missing, conflicting, not applicable, and unknown. The difference between "referenced but missing" and "unknown" matters. The first is a broken link; the second is an absence of information about whether the item ever existed.
The obligation gate requires the executed lease or other documented basis, the tract and acreage used, the rate, the calculation, and the approval role. The payee gate requires the legal payee, the tax classification, the address or payment instruction, and the authority evidence for the signer or representative.
The release gate requires the approval and the instrument or batch record. The delivery gate requires evidence that the payee received the payment or that it was sent to the address of record. The clearing gate requires a bank debit, ACH trace, cleared check, or other confirmation that value moved. An image of an instrument alone belongs to release, not clearing.
Data sources and methodology
The study uses a consecutive cohort of obligations from a declared period and one workflow version. The cohort frame should be the payment register or obligation log, not a folder inventory, because a folder inventory over-represents files that someone chose to keep. Record the frame date, the query, the record count, and exclusions.
| Measure |
Numerator |
Denominator |
Reported with |
| Obligation completeness |
Units with all obligation fields accepted |
All eligible units |
Missing-field counts |
| Payee completeness |
Units with payee and authority evidence |
Units requiring payee review |
Reason mix |
| Release completeness |
Units with approval and instrument record |
Units marked released |
Release date source |
| Delivery completeness |
Units with delivery evidence |
Units marked delivered |
Channel and return status |
| Clearing completeness |
Units with bank or trace confirmation |
Units marked cleared |
Aging from release |
| Chain completeness |
Units with all five gates accepted |
All eligible units |
Gate-level missingness |
The evidence base for this design draws on public guidance about tax information, records management, privacy, and data quality. These sources provide general context and do not decide a particular lease, tract, owner, or payment.
- IRS Form W-9
- IRS Instructions for Form 1099-MISC
- IRS Publication 15
- Treasury unclaimed property resources
- NIST Privacy Framework
- NARA Records Management
- GAO Data Reliability Assessment
- OMB Circular A-130
- Federal Data Strategy
- DOI Natural Resources Revenue Data
Sampling and stratification
If the population is small, review all eligible units. If it is large, draw a reproducible sample before looking at outcomes. Stratify by payment method, project, payee type, and release period. Oversample returned or reissued payments if the question is about failure modes, but report the oversampling and do not present the enriched sample as a population estimate.
A simple random sample supports a description of the population. A risk-based sample supports a review of known weak points but not a prevalence claim. The study report should name the design and avoid confidence language that the sample cannot support.
Field-level data dictionary
Record the obligation identifier, lease identifier, tract identifier, payee identifier, payment method, amount, approval date, release date, delivery date, clearing date, gate states, missing reasons, reviewer, and review date. Define each date's event meaning. A release date is not a clearing date, and a check issue date is not a delivery date.
Keep direct identifiers and banking details in the controlled source system. The analytic table should use study identifiers. If a field is not applicable, record why. Do not use a blank cell for both "not applicable" and "missing," because the two states lead to different conclusions.
Reliability review
Two reviewers should independently classify a planned subset using the same codebook. Report raw agreement and a chance-adjusted statistic when prevalence permits. Preserve the initial ratings before adjudication. If disagreement clusters around one gate, the definition is probably ambiguous. Revise the codebook and re-review a fresh subset rather than resolving every case privately.
The reviewer acceptance rule should be explicit. For example, a payee gate may require a reviewer to accept the authority document, while a release gate may only require the presence of an approval record. Mixing those standards produces a completeness rate that cannot be compared across projects.
Analysis and sensitivity
Begin with a flow table: frame, exclusions by reason, eligible units, units reviewed, open units, and missing gates. Report each gate separately and then the all-gate chain. Show counts, denominators, and aging bands. A single average hides the difference between a file missing one minor field and a file missing clearing evidence.
Run sensitivity checks under a strict definition and an operational definition. The strict definition requires reviewer acceptance for every gate. The operational definition accepts a documented substitute, such as a bank statement that identifies the payee and amount. If the ranking of projects changes under the two definitions, report the instability.
Bias and alternate explanations
A completeness rate can be influenced by project mix, payment method, staff turnover, system migration, and the age of the file. Older files may look less complete because the evidence was stored in a system that is no longer searchable. Newer files may look better because the template was introduced recently. Compare like-for-like periods and disclose workflow changes.
A file can also look complete while linking the wrong version. A check image with the right amount but the wrong tract is not complete for the obligation. The review should test identifiers, not only document presence.
Use the minimum data needed for the study. Restrict access to the analytic table. Do not publish payee names, amounts tied to identifiable owners, banking details, or personal information. Aggregate small cells or suppress them. Follow the client's retention rule and the applicable privacy policy.
Decision threshold and use
Before analysis, define what result triggers a file review, a larger sample, or a controlled remediation. A low chain-completeness rate might trigger a project-level review. A high rate with a cluster of clearing gaps might trigger a bank reconciliation review. The threshold should not make an automatic payment, legal, or ownership decision.
The study is successful if it produces a repeatable measure and a short list of the first failed gate. It is not successful if it produces a single percentage that nobody can trace back to a definition.
Worked analytic scenario
A team freezes one quarter of obligations from the payment register. It excludes duplicate records and obligations outside the workflow version. Two reviewers classify a 30-unit subset, compare results, and clarify the delivery definition. The analyst then reports the gate table, the all-gate chain, the missingness, and the age of open items.
The output is a prioritized review list: obligations missing clearing evidence first, then payee authority, then delivery. The project owner decides who may see the list and what follow-up is permitted. The list is a review aid, not a finding of misconduct or a legal conclusion.
Limitations
This design measures documented evidence, not whether a payment was substantively correct. It cannot establish ownership, title, or the validity of a payee's claim. It also cannot prove that an undocumented payment did not occur. A missing record may reflect a records problem, a system migration, or an actual process failure, and the study should say which explanation is supported by evidence.
Frequently asked questions
Is this a study of payment accuracy?
No. It measures whether the file contains the evidence needed to review a payment. Accuracy of the underlying obligation is a separate question for the authorized reviewer.
Can the design be used for a single project?
Yes. A census of one project is often more useful than a small sample across many projects, provided the project's workflow and population are clearly described.
What is the most common measurement mistake?
Using one "paid" date for release, delivery, and clearing. That collapses three different events and hides where the process actually stops.
Conclusion
Lease bonus evidence is a chain, not a folder. The useful measure is the proportion of obligations that pass each gate, with missingness and aging shown beside the result. Teams that adopt this design can compare projects, target the first failed gate, and give auditors a reproducible path from the obligation to the bank record. They can also avoid the more common failure: declaring a file complete because it contains a check image.
For a controlled review of your own payment evidence, Book a free consultation. The division order signature return cycle study applies a similar measurement approach to owner-facing signature work.
