Payments Received

Payments Received defines a receipts log for money received against invoices. Its recommended approach matches each receipt to an invoice number and uses the bank statement as the reference rather than re-keying both sides. The proposed workflow receives the payment, matches it to an invoice, records it and reconciles it, with unmatched payments treated as disputes. It belongs to the Operate layer and fits the Starter stage. Matching is the control around which the later reporting is organized.

The default deliverable is a short recommendation. An explicit setup, build or conversion request produces artifacts after essential missing facts are resolved. Advice receives a direct answer, while a review works from the material provided. This keeps the size of the proposed setup tied to the requested outcome.

Use it for a payments-received log, receipts register or invoice payment tracker. It does not move money or connect to a bank feed. It does not calculate payroll, tax, leave balances or KPIs.

This is an empty-template workflow, not processing of real employee or customer records. Automation, reminders and synchronization require the separate integration layer. Sensitive decisions and adjustments require qualified human review before anything is acted on.

Intake covers receipt volume, bank transfers and other payment methods, manual versus bank-feed matching, who matches payments, reconciliation frequency, accounts receivable, dispute handling and the accounting package already in use. It distinguishes a receipts log from a reconciliation view or a need for both. Questions are asked one at a time, excluding anything already answered in earlier messages. Unknown facts stay unknown. Intent, confirmed facts, open questions and requested formats remain internal unless the user asks to inspect them; no missing answer is invented.

The field model includes Payment Reference (text); Client (text); Invoice (relation); Amount (currency); Currency (text); Payment Date (date); Payment Method (select); Withholding Tax Deducted (currency); Bank Account (text); Received By (text); Receipt Sent (checkbox); Notes (long_text); Payment ID (id).

Payment Method starts with Bank Transfer, UPI, Card, Cash, Cheque, NEFT/RTGS.

The Invoice field is a relation; Amount and Withholding Tax Deducted are currency fields. Receipt Sent is a checkbox, and Payment ID preserves a source identifier during Notion import. notification-reminder-hub is the related module for due-date reminders; it is separate from this empty record design.

Requested CSV, SQL DDL, JSON Schema and Notion mappings derive from one field list. Display names remain identical across CSV and JSON, and normalized SQL identifiers are documented. Relation fields keep their relational meaning, dates remain dates and money remains currency. Machine-readable data is separated from explanation, with validation failures and limitations reported separately.

One supplied SQL example is:

CREATE TABLE payments_received (
  payment_reference VARCHAR(255),
  client VARCHAR(255),
  invoice VARCHAR(255),  -- relation -> target record
  amount NUMERIC(14,2) NOT NULL,
  currency VARCHAR(255),
  payment_date DATE NOT NULL,
  payment_method VARCHAR(100) NOT NULL,
  withholding_tax_deducted NUMERIC(14,2) NOT NULL,
  bank_account VARCHAR(255),
  received_by VARCHAR(255),
  receipt_sent BOOLEAN NOT NULL,
  notes TEXT,
  payment_id SERIAL PRIMARY KEY,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

Excel-compatible CSV uses UTF-8 with a byte order mark. Because CSV has no column types, numeric, date and currency formatting is identified after the data. A CSV is not an .xlsx workbook; the latter is generated only when requested. Example rows require an explicit request and must be clearly synthetic. Sensitive identifiers are not unnecessarily repeated in a review, and generated templates remain empty.

Notion output goes to notion-manual-import for the CSV, property mapping, import steps and verification checklist. Manual mappings require no connection. Requested workspace changes require verified tool access, the actual target and authorization; a claimed connection is insufficient evidence. Notion relation columns resolve only after both databases have been imported. Select options are an initial vocabulary that can be renamed to match the business. Personal identifiers and sensitive financial details stay out of generated templates.