Unrecorded Liabilities Subsequent Disbursements Search Procedure
Search supplied subsequent payments for items dated on the balance date that were not matched to a recorded liability and total their possible unrecorded exposure.
Description
A search for unrecorded liabilities needs evidence connecting payment with an earlier obligation.
A search for unrecorded liabilities needs evidence connecting payment with an earlier obligation. This tool accepts only day-offset and amount rows, so its selection is a very narrow proxy.1
The returned values include Possible unrecorded items, Possible unrecorded indices, Possible unrecorded total, Payments searched. The How section below explains the calculation, input rules and interpretation.
When to use Unrecorded Liabilities Subsequent Disbursements Search Procedure
Use Unrecorded Liabilities Subsequent Disbursements Search Procedure when you need to evaluate the supplied records under the calculation and evidence rules below. Positive subsequent-day offsets are never selected. There is no recorded-liability matching flag, despite the implementation's short description mentioning a match. This does not perform a complete subsequent-disbursement search or prove an unrecorded obligation.
Prepare source-backed observations and the applicable engagement policy before entering facts. Use consistent monetary units and periods. Supply all boolean evidence flags explicitly, and treat a successful screen as a reason to continue professional review.
How to use Unrecorded Liabilities Subsequent Disbursements Search Procedure and understand its results
- Prepare source-backed observations and the applicable engagement policy before entering facts. Use consistent monetary units and periods. Supply all boolean evidence flags explicitly, and treat a successful screen as a reason to continue professional review.
- Enter payments using the field table and calculation rules, then run the tool.
- Read possibleUnrecordedCount, possibleUnrecordedIndices, possibleUnrecordedTotal, paymentsSearched. The explanation below defines the units, signs, ordering and any flags or placeholder values.
- If the tool reports an input issue, correct the values and run it again. Apply the stated assumptions when interpreting a successfully returned result.
| Input field | Meaning | Value type; see rules below | Requirement |
|---|---|---|---|
| payments | Rows ordered as whole days after the balance date and positive payment amount. | list of list of number | Required |
Supply rows [finite nonnegative daysAfterBalance, finite strictly positive amount], possibly empty. Select only exact zero-day offsets and return original zero-based indexes, count, checked count and checked summed amount.
selected=daysAfterBalance=0; exposure=sum selected amounts Units, indexing, boundary conditions and exceptional cases are defined in the calculation rules above.
| Output field | Meaning | Value type |
|---|---|---|
| possibleUnrecordedCount | Possible unrecorded items | integer; minimum: 0 |
| possibleUnrecordedIndices | Possible unrecorded indices | list of number |
| possibleUnrecordedTotal | Possible unrecorded total | number; minimum: 0 |
| paymentsSearched | Payments searched | integer; minimum: 0 |
{
"input": {
"payments": [
[
0,
12000
],
[
1,
4000
],
[
0,
7500
]
]
},
"output": {
"possibleUnrecordedCount": 2,
"possibleUnrecordedIndices": [
0,
2
],
"possibleUnrecordedTotal": 19500,
"paymentsSearched": 3
}
} Limitations and assumptions
Positive subsequent-day offsets are never selected. There is no recorded-liability matching flag, despite the implementation's short description mentioning a match. This does not perform a complete subsequent-disbursement search or prove an unrecorded obligation.
Numeric inputs, where present, must be finite. Follow the calculation-specific rules for overflow, underflow and exceptional cases. Core numeric and string lists are limited to 100,000 entries; text entries are subject to the general large-text limit. Follow any smaller calculation limits above. Matrices are limited to 128 rows and 128 entries per row. Missing fields without a declared default, extra fields, wrong value types and violations of the calculation rules are input errors.
Alternative or Complementary methods
Use Subsequent Disbursement Postdated Check Review Window: A subsequent-payment review window has both a day-offset allowance and an explicit end date. A payment must fit both constraints. For a complementary task, use Contingency Range Accrual Policy Consistency Checker: A contingency accrual can be checked against both an estimate range and an explicitly applicable policy minimum. These outputs are independent.
References
Similar or alternative tools
- Subsequent Disbursement Postdated Check Review Window
A subsequent-payment review window has both a day-offset allowance and an explicit end date. A payment must fit both constraints.
- Contingency Range Accrual Policy Consistency Checker
A contingency accrual can be checked against both an estimate range and an explicitly applicable policy minimum. These outputs are independent.