Lapping Receipt Delay Pattern Detector

Flag equal-value receipts associated with different customer accounts inside a caller-selected posting-delay window for follow-up as possible lapping patterns. A match is an investigative lead, not proof of fraud.

Description

Possible lapping patterns can involve equal amounts applied across different customers.

Possible lapping patterns can involve equal amounts applied across different customers. A matching pair is an investigative lead.^[1]

The returned values include Potential patterns, Potential pattern indices, Value at risk. The How section below explains the calculation, input rules and interpretation.

When to use Lapping Receipt Delay Pattern Detector

Use Lapping Receipt Delay Pattern Detector when you need to evaluate the supplied records under the calculation and evidence rules below. The error text mentions same-counterparty but the implemented fourth column is 1 for different customer. No fraud, chronology or actual account linkage is proven.

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 Lapping Receipt Delay Pattern Detector 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 maximumDelayDays, paymentReceiptPairs using the field table and calculation rules, then run the tool.
Read patternCount, suspiciousPairIndices, valueAtRisk. 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
maximumDelayDays	Maximum whole-day delay used for pattern screening.	integer; minimum: 0	Required
paymentReceiptPairs	Rows ordered as first receipt amount, later receipt amount, posting delay days, and different-customer flag (0 or 1).	list of list of number	Required

Require nonnegative safe-integer maximum and rows [positive finite payment,positive finite receipt,nonnegative finite delay,binary differentCustomer]. Return selected zero-based indexes/count and checked receipt-amount total. Fractional delays allowed; equality comparisons are exact.

suspicious=differentCustomer1 AND delay≤maximum AND payment=receipt

Units, indexing, boundary conditions and exceptional cases are defined in the calculation rules above.

Output field	Meaning	Value type
patternCount	Potential patterns	integer; minimum: 0
suspiciousPairIndices	Potential pattern indices	list of number
valueAtRisk	Value at risk	number; minimum: 0

json

{
  "input": {
    "maximumDelayDays": 10,
    "paymentReceiptPairs": [
      [
        10000,
        10000,
        3,
        1
      ],
      [
        5000,
        4900,
        2,
        1
      ],
      [
        2000,
        2000,
        12,
        1
      ]
    ]
  },
  "output": {
    "patternCount": 1,
    "suspiciousPairIndices": [
      0
    ],
    "valueAtRisk": 10000
  }
}

Limitations and assumptions

The error text mentions same-counterparty but the implemented fourth column is 1 for different customer. No fraud, chronology or actual account linkage is proven.

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 Kickback Vendor Bid Splitting Invoice Analytics Checker: Bid splitting can involve multiple individually subthreshold amounts whose aggregate reaches an approval limit. Vendor normalization groups text keys for a first screen. For a complementary task, use Ghost Employee Payroll Masterfile Match Tester: Payroll masterfile anomalies can include duplicate identities, shared bank accounts and active workers without an account. Each needs investigation in context.

References

Lapping Receipt Delay Pattern Detector — tool.io

Similar or alternative tools

Kickback Vendor Bid Splitting Invoice Analytics Checker
Bid splitting can involve multiple individually subthreshold amounts whose aggregate reaches an approval limit. Vendor normalization groups text keys for a first screen.
Ghost Employee Payroll Masterfile Match Tester
Payroll masterfile anomalies can include duplicate identities, shared bank accounts and active workers without an account. Each needs investigation in context.