Purchase Accounting

Purchase Accounting defines a Growth-stage Record workflow for verified purchase invoices. Keep one record per verified invoice with purchase-order, delivery-challan and filed-source-document relations, VAT and TDS figures, classification and review status. The five steps are invoice verification, document filing, Purchase VAT Register updating, booking and classification in accounting software, and review against the originals. Linking support and review status makes missing tax treatment or classification visible before filing. The workflow describes what authorized staff must do; generating the register does not perform those actions.

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 purchase invoice register, supplier-bill entry tracker or VAT and TDS log where verified invoices need a traceable document trail. It does not post to accounting software, run supplier payments, compute taxes, file VAT 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 monthly bill and supplier counts; whether purchase orders and challans are available and who verifies invoices; applicable VAT and TDS, inventory versus expense or fixed-asset classification and ledger ownership; the current system and omissions; and whether a purchase register, VAT input log or both are required. 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 Purchase Number (text); Supplier (text); Supplier PAN/VAT (text); Purchase Order (relation); Delivery Challan (relation); Supplier Invoice Number (text); Invoice Date (date); Item/Expense Description (text); Quantity (number); UOM (select); Rate (currency); Gross Amount (currency); VAT Rate % (number); VAT Amount (currency); TDS Rate % (number); TDS Amount (currency); Net Payable (currency); Classification (select); Ledger Account (text); Source Document (relation); Payment Status (select); Amount Paid (currency); Balance (currency); VAT Register Updated (select); Entry Verified (select); Prepared By (text); Verified By (text); Notes (long_text); Purchase ID (id).

UOM starts with Nos, Kg, Litre, Metre, Set, Hour, Box, Packet. Classification starts with Inventory/Purchase, Expense, Fixed Asset, Other. Payment Status starts with Unpaid, Part Paid, Paid, Overdue. VAT Register Updated starts with Not started, In progress, Blocked, Done, Cancelled. Entry Verified starts with Not started, In progress, Blocked, Done, Cancelled.

Purchase Order links the order used for booking; Delivery Challan evidences goods receipt; Source Document links the filed invoice and support. Related workflows include source-document-filing, tds-booking-payment, payment-accounting, expense-accounting, inventory-stock-reconciliation and party-ledger-reconciliation; accounting-audit-system-builder routes among these modules.

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 purchase_accounting (
  purchase_number VARCHAR(255),
  supplier VARCHAR(255),
  supplier_pan_vat VARCHAR(255),
  purchase_order VARCHAR(255),  -- relation -> target record
  delivery_challan VARCHAR(255),  -- relation -> target record
  supplier_invoice_number VARCHAR(255),
  invoice_date DATE NOT NULL,
  item_expense_description VARCHAR(255),
  quantity NUMERIC NOT NULL,
  uom VARCHAR(100) NOT NULL,
  rate NUMERIC(14,2) NOT NULL,
  gross_amount NUMERIC(14,2) NOT NULL,
  vat_rate_pct NUMERIC NOT NULL,
  vat_amount NUMERIC(14,2) NOT NULL,
  tds_rate_pct NUMERIC NOT NULL,
  tds_amount NUMERIC(14,2) NOT NULL,
  net_payable NUMERIC(14,2) NOT NULL,
  classification VARCHAR(100) NOT NULL,
  ledger_account VARCHAR(255),
  source_document VARCHAR(255),  -- relation -> target record
  payment_status VARCHAR(100) NOT NULL,
  amount_paid NUMERIC(14,2) NOT NULL,
  balance NUMERIC(14,2) NOT NULL,
  vat_register_updated VARCHAR(100) NOT NULL,
  entry_verified VARCHAR(100) NOT NULL,
  prepared_by VARCHAR(255),
  verified_by VARCHAR(255),
  notes TEXT,
  purchase_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.