Source Document & Filing

Source Document & Filing defines a Growth-stage Document workflow for an indexed register of supporting documents. Keep one row per document and use a period/party reference key so retrieval works by month and party. Link the row to its accounting voucher and supported transaction. The workflow receives the document, references and indexes it, files it, links it to the entry and verifies it. The register records where support is kept and whether it exists, rather than storing the files itself. Availability and verification fields keep missing support visible in the accounting trail.

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 bill and voucher filing indexes and supporting-document audit trails when entries exist but their evidence cannot be found. It does not scan, store or digitize documents, set retention policy, perform daily bookkeeping, file tax returns or give legal advice.

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.

Establish document types and monthly volume; physical versus digital filing and naming; existing indexing by period or party; business retention requirements, applicable rules and disposal owner; and whether a register, reindexing plan or both are needed. 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 Document Reference (text); Document Type (select); Document Number (text); Document Date (date); Party Name (text); Party PAN/VAT (text); Amount (currency); Currency (text); Tax Amount (currency); TDS Amount (currency); Source Department (select); Index Key (text); Storage Location (text); Retention Period (text); Linked Voucher (relation); Linked Transaction (relation); Document Availability (select); Verification Status (select); Verified By (text); Verified Date (date); Notes (long_text); Document Filing ID (id).

Document Type starts with Purchase Invoice, Sales Invoice, Purchase Order, Sales Order, Delivery Challan, Receipt, Payment Voucher, Bank Statement, Cheque Record, Expense Bill, Contract/Agreement, Salary Sheet, Wage Sheet, Tax Document, TDS Document, Import Document, Fixed Asset Invoice, Other. Source Department starts with Sales, Purchase, Accounts, Payroll, Admin, Finance. Document Availability starts with Original on file, Copy on file, Awaiting from party, Not available, Duplicate. Verification Status starts with Not started, In progress, Blocked, Done, Cancelled.

Linked Voucher points to the accounting voucher; Linked Transaction points to the purchase, sales or payment record supported. Index Key uses period/party, with 2026/08/BLUEPEAK as a synthetic format example, not an actual business record. Related workflows are purchase-accounting, sales-accounting and payment-accounting for supported entries, audit-preparation for evidence requests, and accounting-audit-system-builder for routing.

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 source_document_filing (
  document_reference VARCHAR(255),
  document_type VARCHAR(100) NOT NULL,
  document_number VARCHAR(255),
  document_date DATE NOT NULL,
  party_name VARCHAR(255),
  party_pan_vat VARCHAR(255),
  amount NUMERIC(14,2) NOT NULL,
  currency VARCHAR(255),
  tax_amount NUMERIC(14,2),
  tds_amount NUMERIC(14,2),
  source_department VARCHAR(100) NOT NULL,
  index_key VARCHAR(255),
  storage_location VARCHAR(255),
  retention_period VARCHAR(255),
  linked_voucher VARCHAR(255),  -- relation -> target record
  linked_transaction VARCHAR(255),  -- relation -> target record
  document_availability VARCHAR(100) NOT NULL,
  verification_status VARCHAR(100) NOT NULL,
  verified_by VARCHAR(255),
  verified_date DATE,
  notes TEXT,
  document_filing_id SERIAL PRIMARY KEY,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

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.