Skip to main content

investigate-a-payment-discrepancy

Investigate a consequential payment mismatch through preserved evidence, reconciliation, containment, and recovery. Use when a payment may be duplicated, diverted, altered, missing, unauthorized, or posted to the wrong party.

Source facts

Repository
protosphinx/sphinxstack
Last source activity
July 29, 2026 at 13:55
Detected SKILL.md language
English
Stars
3
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
investigate-a-payment-discrepancy
category
money
description
Investigate a consequential payment mismatch through preserved evidence, reconciliation, containment, and recovery. Use when a payment may be duplicated, diverted, altered, missing, unauthorized, or posted to the wrong party.
# investigate-a-payment-discrepancy ## When to use - Use when a payment anomaly could involve material loss, control failure, identity change, or misconduct. - Use purchase-order reconciliation for a routine documented invoice mismatch with no fraud indicator. ## Preconditions - Confirm incident authority, evidence custodian, financial-system owners, privacy boundary, materiality, communication channel, and escalation contacts. ## Procedure 1. Open a restricted case and preserve original messages, approvals, system events, bank records, supplier records, and timestamps before making changes. 2. Establish evidence preservation rules, legal or regulatory escalation, chain of custody, and a ban on confronting a suspected actor without authority. 3. Build a payment chronology from request through master-data change, approval, release, settlement, receipt, posting, and discovery. 4. Create a transaction reconciliation across ledger, subledger, bank, payment processor, invoice, order, receipt, beneficiary, currency, and fees. 5. Verify identity and instructions through known independent channels; do not use contact details supplied in the suspicious request. 6. Map the access boundary across requester, approvers, privileged users, mailboxes, integrations, tokens, devices, and third parties. 7. Contain proportionately by pausing unreleased items, protecting accounts, preserving logs, notifying authorized financial institutions, and avoiding destruction of evidence. 8. Develop and test hypotheses for error, timing, duplicate, compromise, diversion, collusion, or system defect; distinguish fact, inference, and unknown. 9. Make a recovery decision covering recall, dispute, correction, customer or supplier treatment, reporting, and residual risk through qualified owners. 10. Verify ledger correction, fund disposition, access remediation, control improvements, affected-party communication, and recurrence monitoring. ## Failure plan - Stop informal investigation if access, evidence integrity, personal safety, or a regulated reporting deadline may be compromised. - Do not accuse, tip off, delete, reverse, contact a bank, or alter a financial record without the required authority. - Escalate unresolved identity, beneficiary, insider, cross-border, sanctions, legal-hold, or material-loss questions to qualified owners. ## Done - A payment chronology preserves sourced events, gaps, custody, and confidence - A reconciliation ledger accounts for transaction, bank, beneficiary, posting, and correction states - The access boundary and tested hypotheses distinguish confirmed facts from unknowns - A containment and recovery record proves authorized action, fund disposition, accounting correction, control repair, and monitoring
View on GitHub