An invoice marked paid tells you its recorded status; it does not, by itself, establish how money arrived. When a billing team cannot explain the change, check the event that changed the status, the related payment record and independent settlement evidence before asking the customer to pay again.
This checklist is for the person investigating one unexpected Paid badge. It is not a guide to matching an entire bank feed or exporting the month's accounts. Keep the investigation small: one invoice, one customer, one amount and currency, and a dated record of what you can actually establish.
What can the billing activity log establish?
The PayRequest Billing Activity Log documentation describes invoice-status events, invoice email events, filtering by entity and action, and details about who or what performed an action. Search the invoice number or ID, narrow the date range and open the status-change details. A user or System label helps explain the event's origin; it is not bank settlement evidence.
Record the previous status, new status, timestamp, available actor and reason. Preserve the record before taking a corrective action. Not every action necessarily creates a visible entry, and filters can hide older events. An empty search therefore cannot prove that nobody changed the invoice.
Intuit's invoice-status troubleshooting guidance also starts with the audit log when a status is unexpected. Its credit-allocation settings are specific to QuickBooks; do not assume that another billing product has the same automation or correction controls.
Work through an unexplained €600 Paid badge
This is an original fictional example, not a customer result or account test. Invoice INV-DEMO-600 is for €600. A team member sees €400 credited to the relevant bank account, while the invoice displays Paid. Neither amount should be inferred from a screenshot supplied by the payer.
| Evidence layer | Example observation | What remains unresolved |
|---|---|---|
| Invoice record | €600 total; Paid status | Which action caused the status? |
| Activity record | Open changed to Paid; available user and reason recorded | Did that action reflect the full balance? |
| Payment evidence | €400 confirmed bank credit linked to this invoice | Is there a separate €200 payment or valid adjustment? |
| Investigation result | €600 minus €400 leaves €200 unexplained | Confirm adjustments before describing an amount as due |
The €200 is an arithmetic difference, not yet a demand for payment. A credit, refund, second payment or incorrect allocation could change the conclusion. Check those records and the currency before deciding whether the invoice status needs correction. A €600 provider transaction that is pending also does not establish €600 credited to your bank.
Keep three references in the case card
Use a seller-side worksheet; these are suggested investigation fields, not new PayRequest settings:
- Invoice: number, customer, total, currency and current status.
- Event: timestamp with timezone, old/new status, available actor and reason, and where the record was found.
- Money: payment reference, amount, currency, provider or bank state, and the invoice allocation.
Add the owner, open question and next review date. Store only the evidence your team needs and restrict access to financial records. Do not copy full account statements or unrelated customers' transactions into a public ticket.
How should you interpret System or a missing event?
System identifies an automated origin in the documented log; it does not tell you that a person approved the action or that funds settled. Open the available detail and look for the associated invoice or payment reference. If the reason is unclear, ask the billing owner to investigate rather than assigning responsibility from the label alone.
For a missing event, clear filters, search by ID instead of name and expand the date range. Record “event not found in this search,” not “no change occurred.” Compare the invoice timeline and payment records. Do not repeat a debit or resend a demand simply to see whether the badge changes.
Decide the next action before contacting the customer
If the full payment and allocation are verified, retain the matching references and avoid another collection request. If payment is partial, verify any credit or adjustment and agree the remaining action. If the status is unexplained, keep the case open and use your authorized correction process only after establishing the facts. A log explains a billing action; it does not replace your accounting records.
For matching problems, use the missing bank-transfer reference checklist. For a broader matching process, see automated payment reconciliation. These solve different jobs from investigating a status change.
Open one invoice alongside PayRequest's Activity Log and invoicing records. Build the three-reference case card before sending the next reminder.
Editorial note: AI assisted with this article and cover. Documentation and relevant product code were reviewed on 7 October 2026. The example is illustrative; no live payment or customer account was tested.
