{
  "@context": "https://mith.tech/concepts.json",
  "name": "Mith Tech Business Systems Encyclopedia",
  "description": "Definitions of the business objects that ERP, commerce and accounting systems implement, with lifecycles, invariants, common mistakes and ERPNext mappings.",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "source": "https://mith.tech/concepts",
  "count": 24,
  "concepts": [
    {
      "conceptId": "customer",
      "title": "Customer",
      "domain": "Sales",
      "url": "https://mith.tech/concepts/customer",
      "definition": "A customer is a party that has an established commercial relationship with a business and can be billed for goods or services.",
      "aliases": [
        "Account",
        "Buyer",
        "Client",
        "Debtor",
        "Party"
      ],
      "relationships": [
        {
          "predicate": "has",
          "target": "contact",
          "note": "One or many people. A person, not a billing party."
        },
        {
          "predicate": "has",
          "target": "address",
          "note": "Billing and shipping addresses differ and both change."
        },
        {
          "predicate": "creates",
          "target": "sales-order",
          "note": "The commitment to supply."
        },
        {
          "predicate": "receives",
          "target": "invoice",
          "note": "The demand for payment."
        },
        {
          "predicate": "makes",
          "target": "payment",
          "note": "Which settles the invoice, not the order."
        }
      ],
      "lifecycle": [
        {
          "state": "Lead",
          "meaning": "Interest exists; no commercial relationship yet. Not billable."
        },
        {
          "state": "Opportunity",
          "meaning": "A specific potential deal is being pursued."
        },
        {
          "state": "Customer",
          "meaning": "Billable. Has transacted or is contracted to."
        },
        {
          "state": "Dormant",
          "meaning": "No activity for a defined period. Still billable, excluded from active reporting."
        }
      ],
      "invariants": [
        "A customer must be billable — it needs a legal name and, in India, a GSTIN if registered.",
        "A customer is not the same object as a contact: a contact is a person, a customer is a billing party.",
        "Deleting a customer with posted transactions must be impossible; deactivation is the only correct operation."
      ],
      "commonMistakes": [
        {
          "mistake": "Creating a new customer record per order or per branch",
          "why": "Receivables fragment across duplicates, credit limits stop working, and the same buyer appears three times in every report. Almost always the single largest data-quality problem in a migration."
        },
        {
          "mistake": "Storing contacts and addresses as fields on the customer",
          "why": "A customer has many of each, and they change independently. Flattening them means losing history and breaking multi-site delivery the first time a buyer ships to two places."
        },
        {
          "mistake": "Using customer groups as legal entities",
          "why": "Groups are for pricing and reporting. A separate legal entity needs its own company or GSTIN, not a group label — the tax treatment differs."
        }
      ],
      "edgeCases": [
        "A buyer who is also a supplier — the same legal entity needs both a Customer and a Supplier record, and netting between them is a manual decision, not automatic.",
        "Multi-GSTIN buyers: one legal name, several registrations, each requiring its own place-of-supply treatment.",
        "Consumer sales with no registration at all, where the invoice is B2C and the reporting threshold differs."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Customer",
            "note": "The billing party. `customer_group` is for pricing/reporting, not legal structure."
          },
          {
            "doctype": "Contact",
            "note": "Linked via Dynamic Link, not a field on Customer — which is why one contact can serve several parties."
          },
          {
            "doctype": "Address",
            "note": "Also a Dynamic Link. `is_primary_address` and `is_shipping_address` are separate flags."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-13",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "invoice",
      "title": "Invoice",
      "domain": "Finance",
      "url": "https://mith.tech/concepts/invoice",
      "definition": "An invoice is a document that creates a legally enforceable obligation for a buyer to pay a seller a stated amount by a stated date.",
      "aliases": [
        "Bill",
        "Tax invoice",
        "Sales invoice",
        "Receivable"
      ],
      "relationships": [
        {
          "predicate": "issuedTo",
          "target": "customer"
        },
        {
          "predicate": "derivedFrom",
          "target": "sales-order",
          "note": "Optionally — an invoice can stand alone."
        },
        {
          "predicate": "settledBy",
          "target": "payment",
          "note": "Partially or fully; one invoice may take many payments."
        },
        {
          "predicate": "reversedBy",
          "target": "credit-note"
        },
        {
          "predicate": "posts",
          "target": "general-ledger"
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Editable. No ledger impact, no legal force."
        },
        {
          "state": "Submitted",
          "meaning": "Posted to the ledger, immutable, receivable created."
        },
        {
          "state": "Partly paid",
          "meaning": "One or more payments applied; a balance remains."
        },
        {
          "state": "Paid",
          "meaning": "Outstanding is zero."
        },
        {
          "state": "Cancelled",
          "meaning": "Reversed with an equal and opposite ledger entry. The document remains, for audit."
        }
      ],
      "invariants": [
        "An invoice must post to the general ledger; an unposted invoice is a draft, not an invoice.",
        "An invoice's total must equal the sum of its lines plus taxes, always — no rounding plug.",
        "A posted invoice is immutable. Corrections happen via credit note, never by editing.",
        "In India, a tax invoice must carry a GSTIN, a place of supply and an unbroken serial number."
      ],
      "commonMistakes": [
        {
          "mistake": "Editing a posted invoice to fix an error",
          "why": "It breaks the audit trail and, once e-invoicing is on, desynchronises you from the IRP — which has already recorded the original. The credit note exists precisely for this."
        },
        {
          "mistake": "Treating the invoice as the moment revenue is earned",
          "why": "Revenue is earned on delivery of the obligation, which may be before or after invoicing. Conflating them misstates period cut-off."
        },
        {
          "mistake": "Invoicing directly from the order and skipping delivery",
          "why": "You lose the ability to detect the case where invoiced quantity and delivered quantity differ — the single most common source of disputed receivables."
        }
      ],
      "edgeCases": [
        "Partial delivery: invoicing 100 units when 80 shipped creates a dispute the system should have prevented.",
        "Advance received before invoice — the payment exists with nothing to settle, and must sit against the customer, not an invoice.",
        "Credit note issued in a later tax period than the invoice it reverses, which changes which return each lands in.",
        "Foreign-currency invoices, where the receivable revalues but the invoice does not."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Sales Invoice",
            "note": "`docstatus` 0 draft / 1 submitted / 2 cancelled — the immutability boundary is 0→1."
          },
          {
            "doctype": "GL Entry",
            "note": "Written on submit. Never edited directly; a GL Entry you can edit is a corrupted ledger."
          },
          {
            "doctype": "Payment Entry",
            "note": "Settles via Payment Reference rows, which is what allows part-payment."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-13",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "purchase-order",
      "title": "Purchase Order",
      "domain": "Procurement",
      "url": "https://mith.tech/concepts/purchase-order",
      "definition": "A purchase order is a buyer's binding commitment to acquire specified goods or services from a supplier at agreed terms.",
      "aliases": [
        "PO",
        "Order",
        "Procurement order"
      ],
      "relationships": [
        {
          "predicate": "issuedTo",
          "target": "supplier"
        },
        {
          "predicate": "fulfilledBy",
          "target": "purchase-receipt",
          "note": "Possibly several, for partial deliveries."
        },
        {
          "predicate": "billedBy",
          "target": "purchase-invoice"
        },
        {
          "predicate": "requires",
          "target": "approval-workflow"
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Being prepared. No commitment."
        },
        {
          "state": "Pending approval",
          "meaning": "Awaiting authorisation at the required level."
        },
        {
          "state": "Approved / sent",
          "meaning": "Committed. The supplier may act on it."
        },
        {
          "state": "Partially received",
          "meaning": "Some quantity delivered; the balance is outstanding."
        },
        {
          "state": "Received",
          "meaning": "Delivery complete."
        },
        {
          "state": "Closed",
          "meaning": "Billed and settled, or deliberately terminated short."
        }
      ],
      "invariants": [
        "A purchase order commits money; it must therefore pass whatever approval the amount requires before it is sent.",
        "Received quantity may never silently exceed ordered quantity — over-receipt is a decision, not a default.",
        "A purchase order is not an invoice and creates no payable on its own."
      ],
      "commonMistakes": [
        {
          "mistake": "Skipping approval rules because they slow people down",
          "why": "The control exists to stop unbudgeted spend. Removed, the first thing you lose is the ability to answer who authorised a payment — usually discovered during an audit."
        },
        {
          "mistake": "Using the purchase order as the invoice",
          "why": "The supplier's invoice is the payable. Paying from the order means paying for goods that may not have arrived, in the quantity ordered rather than received."
        },
        {
          "mistake": "Not handling partial receipt",
          "why": "Real deliveries are partial constantly. A system that cannot represent 60 of 100 received forces staff into a spreadsheet, and the stock ledger stops being true."
        }
      ],
      "edgeCases": [
        "Over-receipt within tolerance, which is legitimate for bulk commodities and fraud everywhere else.",
        "Price on the supplier's invoice differing from the order — a three-way match failure that needs a human, not a rule.",
        "Subcontracting, where materials you own are consumed at someone else's site.",
        "Services with no receipt event at all, where billing is the only confirmation the work happened."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Purchase Order",
            "note": "`per_received` and `per_billed` drive status — they are percentages, so partial flows are first-class."
          },
          {
            "doctype": "Purchase Receipt",
            "note": "The goods event. Moves stock; does not create a payable."
          },
          {
            "doctype": "Purchase Invoice",
            "note": "The money event. Creates the payable."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-13",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "sales-order",
      "title": "Sales Order",
      "domain": "Sales",
      "url": "https://mith.tech/concepts/sales-order",
      "definition": "A sales order is a seller's confirmed commitment to supply specified goods or services to a customer at agreed prices and dates.",
      "aliases": [
        "SO",
        "Confirmed order",
        "Customer order",
        "Order acknowledgement"
      ],
      "relationships": [
        {
          "predicate": "placedBy",
          "target": "customer"
        },
        {
          "predicate": "derivedFrom",
          "target": "quotation",
          "note": "Optionally — a repeat order may skip quoting entirely."
        },
        {
          "predicate": "fulfilledBy",
          "target": "delivery-note",
          "note": "Possibly several, for partial shipment."
        },
        {
          "predicate": "billedBy",
          "target": "invoice"
        },
        {
          "predicate": "reserves",
          "target": "item",
          "note": "Committed stock is not available stock."
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Being prepared. No commitment on either side."
        },
        {
          "state": "Confirmed",
          "meaning": "Both parties agreed. Stock or capacity is committed."
        },
        {
          "state": "Partially delivered",
          "meaning": "Some quantity shipped; a balance remains outstanding."
        },
        {
          "state": "Delivered",
          "meaning": "Fulfilment complete. Billing may still be outstanding."
        },
        {
          "state": "Closed",
          "meaning": "Delivered and billed, or deliberately terminated short of full quantity."
        },
        {
          "state": "Cancelled",
          "meaning": "Terminated before fulfilment. Reservations released."
        }
      ],
      "invariants": [
        "A sales order commits inventory or capacity; confirming one you cannot fulfil is a promise, not a record.",
        "Delivered quantity may never silently exceed ordered quantity — over-delivery is a decision someone makes, not a default.",
        "A sales order creates no accounting entry. Revenue arrives with delivery and invoicing, not with the order."
      ],
      "commonMistakes": [
        {
          "mistake": "Treating the order as the revenue event",
          "why": "It is a commitment, not a transaction. Booking revenue at order time overstates the period and produces the classic reversal when the order is cancelled or amended."
        },
        {
          "mistake": "Amending a confirmed order in place, with no record of what changed",
          "why": "The customer agreed to a specific version. Silent amendment is the origin of most delivery disputes, because neither side can show what was actually agreed."
        },
        {
          "mistake": "Not reserving stock against confirmed orders",
          "why": "Two salespeople sell the same last unit. The system said it was available because nothing had claimed it — this is the single most common cause of a stockout that the report says cannot happen."
        }
      ],
      "edgeCases": [
        "Partial delivery against a single order line, where the balance may or may not still be wanted by the time it is available.",
        "Price changing between order and delivery — whether the order price or the current price applies is a commercial policy, not a system default.",
        "Drop-ship orders, where stock never enters your warehouse and the delivery event is somebody else's.",
        "Service orders with no delivery event at all, where invoicing is the only confirmation the work happened."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Sales Order",
            "note": "`per_delivered` and `per_billed` are percentages, so partial flows are first-class rather than an exception."
          },
          {
            "doctype": "Delivery Note",
            "note": "The goods event. Moves stock and posts the COGS entry; creates no receivable."
          },
          {
            "doctype": "Sales Invoice",
            "note": "The money event. Creates the receivable. Can be raised with or without a delivery note."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "delivery-note",
      "title": "Delivery Note",
      "domain": "Inventory",
      "url": "https://mith.tech/concepts/delivery-note",
      "definition": "A delivery note is the record that specified goods physically left the seller's control and were transferred to the buyer.",
      "aliases": [
        "DN",
        "Dispatch note",
        "Goods issue",
        "Challan",
        "Packing slip"
      ],
      "relationships": [
        {
          "predicate": "fulfils",
          "target": "sales-order"
        },
        {
          "predicate": "reduces",
          "target": "item",
          "note": "Stock leaves the warehouse here, not at invoicing."
        },
        {
          "predicate": "precedes",
          "target": "invoice",
          "note": "Usually — but services and advance billing invert this."
        },
        {
          "predicate": "reversedBy",
          "target": "return"
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Prepared, not yet dispatched. No stock movement."
        },
        {
          "state": "Submitted",
          "meaning": "Goods issued. Stock ledger and COGS posted."
        },
        {
          "state": "Returned",
          "meaning": "Some or all quantity came back; a reverse movement exists."
        },
        {
          "state": "Cancelled",
          "meaning": "Reversed with an equal and opposite stock entry. The document survives for audit."
        }
      ],
      "invariants": [
        "A delivery note moves stock. If it posts no stock movement, it is paperwork, not a delivery note.",
        "The quantity delivered is a physical fact, not a commercial one — it must reflect what actually shipped, even when that differs from what was ordered or invoiced.",
        "In India, a delivery challan is a statutory document for movement of goods, and its number and date are legally relevant."
      ],
      "commonMistakes": [
        {
          "mistake": "Skipping the delivery note and invoicing straight from the order",
          "why": "It removes the only place where ordered, delivered and invoiced quantities can be compared. Every disputed receivable that begins \"but we never received that\" traces back to this."
        },
        {
          "mistake": "Back-dating deliveries to make a period look better",
          "why": "It misstates stock on hand at period end and breaks the reconciliation between the stock ledger and the physical count — which is precisely the check that would have caught it."
        },
        {
          "mistake": "Treating the e-way bill as optional for short movements",
          "why": "The threshold is a value and distance rule, not a judgement call, and the penalty lands on the consignment rather than the paperwork."
        }
      ],
      "edgeCases": [
        "Goods delivered but rejected at the customer's gate — the movement happened and must be reversed, not deleted.",
        "Partial shipment across multiple vehicles on different dates against one order line.",
        "Stock transfers between your own warehouses, which move stock without any sale occurring.",
        "Consignment stock, where goods move but ownership does not — the commonest case of a delivery note that must NOT trigger revenue."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Delivery Note",
            "note": "Submitting posts Stock Ledger Entries and the COGS GL entry — not the receivable."
          },
          {
            "doctype": "Stock Ledger Entry",
            "note": "The immutable movement record. Never edited; corrections are new entries."
          },
          {
            "doctype": "Sales Invoice",
            "note": "Can be created from the delivery note, which is what keeps delivered and invoiced quantities aligned."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "payment",
      "title": "Payment",
      "domain": "Finance",
      "url": "https://mith.tech/concepts/payment",
      "definition": "A payment is a transfer of money that discharges some or all of an obligation between two parties.",
      "aliases": [
        "Receipt",
        "Remittance",
        "Settlement",
        "Payment entry"
      ],
      "relationships": [
        {
          "predicate": "madeBy",
          "target": "customer"
        },
        {
          "predicate": "settles",
          "target": "invoice",
          "note": "Partially or fully; one payment may settle several invoices."
        },
        {
          "predicate": "posts",
          "target": "general-ledger"
        },
        {
          "predicate": "reconciledAgainst",
          "target": "bank-statement"
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Recorded, not posted. No ledger impact."
        },
        {
          "state": "Submitted",
          "meaning": "Posted. Cash and receivable both move."
        },
        {
          "state": "Reconciled",
          "meaning": "Matched to a bank statement line. Now independently verified."
        },
        {
          "state": "Cancelled",
          "meaning": "Reversed with an equal and opposite entry, the document retained."
        }
      ],
      "invariants": [
        "A payment must be allocated against something — an invoice, an advance, or an on-account balance. An unallocated payment is an unexplained credit.",
        "The sum allocated may never exceed the payment amount.",
        "A payment is a bank or cash fact. It must ultimately reconcile to a statement line, or one of the two records is wrong."
      ],
      "commonMistakes": [
        {
          "mistake": "Recording payment against the customer rather than the invoice",
          "why": "Ageing collapses. You can see that they paid, but not what they paid for, so you cannot tell which invoices are genuinely overdue — and collections start chasing settled bills."
        },
        {
          "mistake": "Netting a customer's payment against their supplier balance automatically",
          "why": "Set-off between a receivable and a payable is a legal and commercial decision, and in many jurisdictions it needs agreement. Automating it hides two real balances behind one number."
        },
        {
          "mistake": "Treating an advance as revenue",
          "why": "Money received before the obligation is discharged is a liability, not income. Booking it as revenue overstates the period and understates what you still owe the customer in goods."
        }
      ],
      "edgeCases": [
        "Part payment against several invoices, where allocation order changes which invoices show as overdue.",
        "Overpayment, which becomes a credit balance and is a liability until refunded or applied.",
        "Payment in a currency other than the invoice, where the realised exchange gain or loss belongs to the settlement, not the invoice.",
        "Bounced or reversed payments, which must reopen the invoice rather than silently reducing cash.",
        "Payment received by a salesperson in cash and deposited days later — the date the business received it and the date the bank did are different facts."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Payment Entry",
            "note": "Payment References child rows are what allow one payment to settle several invoices partially."
          },
          {
            "doctype": "Bank Transaction",
            "note": "The statement side. Reconciliation matches the two; an unmatched entry on either side is a real discrepancy."
          },
          {
            "doctype": "Journal Entry",
            "note": "Used for set-off, write-off and adjustments that are not a simple cash movement."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "credit-note",
      "title": "Credit Note",
      "domain": "Finance",
      "url": "https://mith.tech/concepts/credit-note",
      "definition": "A credit note is a document that reduces or cancels an amount a customer owes, by reversing all or part of a previously issued invoice.",
      "aliases": [
        "Credit memo",
        "Sales return invoice",
        "CN",
        "Adjustment note"
      ],
      "relationships": [
        {
          "predicate": "reverses",
          "target": "invoice"
        },
        {
          "predicate": "issuedTo",
          "target": "customer"
        },
        {
          "predicate": "mayReverse",
          "target": "delivery-note",
          "note": "When goods physically come back, the stock movement reverses too."
        },
        {
          "predicate": "posts",
          "target": "general-ledger"
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Prepared. No ledger impact."
        },
        {
          "state": "Submitted",
          "meaning": "Posted. Receivable reduced, revenue and tax reversed."
        },
        {
          "state": "Applied",
          "meaning": "Allocated against a specific invoice or refunded."
        },
        {
          "state": "Cancelled",
          "meaning": "Reversed with an equal and opposite entry."
        }
      ],
      "invariants": [
        "A credit note references the invoice it adjusts. One that references nothing is an unexplained reduction in revenue.",
        "It may not reduce an invoice below zero.",
        "It posts to the ledger like an invoice, in the opposite direction — it is a transaction, not an annotation.",
        "Under Indian GST, a credit note has its own reporting window, and issuing it after that window closes does not recover the tax."
      ],
      "commonMistakes": [
        {
          "mistake": "Editing or cancelling the original invoice instead of issuing a credit note",
          "why": "It destroys the audit trail and, once e-invoicing is on, desynchronises you from the IRP, which already recorded the original. The credit note exists precisely so the correction is itself a record."
        },
        {
          "mistake": "Issuing a credit note for a return without reversing the stock",
          "why": "The money comes back and the goods do not. Inventory overstates by exactly the returned quantity, and the discrepancy compounds silently with every return."
        },
        {
          "mistake": "Using credit notes to apply discounts after the fact",
          "why": "It works accounting-wise and destroys margin analysis: the sale looks full-price and the discount looks like a return, so nobody can see what the product actually sells for."
        }
      ],
      "edgeCases": [
        "Credit note issued in a later tax period than the invoice it reverses, which changes which return each lands in.",
        "Partial return, where the quantity returned and the value credited need not be proportional if the reason is damage rather than rejection.",
        "Credit for a price correction with no goods movement at all — the commonest case, and the one most often modelled wrongly.",
        "Customer with no open invoices, where the credit becomes a standing balance until refunded."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Sales Invoice",
            "note": "With `is_return` = 1. A credit note is a negative sales invoice, not a separate doctype."
          },
          {
            "doctype": "Stock Entry",
            "note": "Only when goods return. A price-adjustment credit note must NOT move stock."
          },
          {
            "doctype": "GL Entry",
            "note": "Posts the reversal. Tax reverses with it, which is what makes the GST timing window matter."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "supplier",
      "title": "Supplier",
      "domain": "Procurement",
      "url": "https://mith.tech/concepts/supplier",
      "definition": "A supplier is a party from which a business acquires goods or services and to which it therefore owes payment.",
      "aliases": [
        "Vendor",
        "Creditor",
        "Payee",
        "Party"
      ],
      "relationships": [
        {
          "predicate": "receives",
          "target": "purchase-order"
        },
        {
          "predicate": "delivers",
          "target": "purchase-receipt"
        },
        {
          "predicate": "issues",
          "target": "purchase-invoice",
          "note": "Their invoice is your payable."
        },
        {
          "predicate": "paidBy",
          "target": "payment"
        }
      ],
      "lifecycle": [
        {
          "state": "Prospective",
          "meaning": "Identified, not yet approved to transact."
        },
        {
          "state": "Approved",
          "meaning": "Onboarded, bank and tax details verified. Orders may be placed."
        },
        {
          "state": "On hold",
          "meaning": "Blocked from new orders — quality, dispute or compliance."
        },
        {
          "state": "Inactive",
          "meaning": "No longer used. History retained."
        }
      ],
      "invariants": [
        "A supplier must be payable — it needs a legal name and bank details before money can move.",
        "A supplier with posted transactions may be deactivated, never deleted.",
        "In India, a supplier's GSTIN determines whether input tax credit can be claimed at all, so it is a commercial field, not an administrative one."
      ],
      "commonMistakes": [
        {
          "mistake": "Duplicate supplier records",
          "why": "Payables fragment, the same vendor appears twice in spend analysis, and negotiated rates apply to one record while orders go to the other. Harder to spot than duplicate customers, because nobody chases a supplier for money."
        },
        {
          "mistake": "Storing bank details only on the payment, not the supplier",
          "why": "Every payment becomes a re-entry, and re-entry is where payment fraud lives. Bank details belong on the master, with a change-approval trail."
        },
        {
          "mistake": "Not recording GSTIN status",
          "why": "Buying from an unregistered supplier changes the tax treatment and may trigger reverse charge. Discovering this at return-filing time means restating the period."
        }
      ],
      "edgeCases": [
        "A supplier who is also a customer — same legal entity, two records, and any netting between them is a deliberate decision.",
        "One-time vendors, where creating a full master is disproportionate but an unnamed payment is unacceptable.",
        "Suppliers who change bank details mid-relationship, which is both a routine event and the standard pretext for payment fraud.",
        "Subcontractors holding your material, where the supplier relationship and the stock ownership diverge."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Supplier",
            "note": "`supplier_group` drives default terms and accounts; it is not a legal classification."
          },
          {
            "doctype": "Bank Account",
            "note": "Linked, not embedded — which is what allows a change trail on the detail that matters most."
          },
          {
            "doctype": "Purchase Invoice",
            "note": "Creates the payable. The goods event is Purchase Receipt and is separate."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "purchase-receipt",
      "title": "Purchase Receipt",
      "domain": "Procurement",
      "url": "https://mith.tech/concepts/purchase-receipt",
      "definition": "A purchase receipt is the record that specified goods physically arrived from a supplier and entered the buyer's control.",
      "aliases": [
        "GRN",
        "Goods receipt note",
        "Inward entry",
        "Receiving report"
      ],
      "relationships": [
        {
          "predicate": "fulfils",
          "target": "purchase-order"
        },
        {
          "predicate": "receivedFrom",
          "target": "supplier"
        },
        {
          "predicate": "increases",
          "target": "item",
          "note": "Stock enters here, not at invoicing."
        },
        {
          "predicate": "matchedAgainst",
          "target": "purchase-invoice",
          "note": "The third leg of the three-way match."
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Prepared, goods not yet accepted. No stock movement."
        },
        {
          "state": "Submitted",
          "meaning": "Goods accepted. Stock ledger posted; a liability accrues but no payable exists yet."
        },
        {
          "state": "Partially billed",
          "meaning": "Supplier has invoiced some of the received quantity."
        },
        {
          "state": "Billed",
          "meaning": "Fully invoiced. The three-way match is complete."
        },
        {
          "state": "Cancelled",
          "meaning": "Reversed with an equal and opposite stock entry, the document retained."
        }
      ],
      "invariants": [
        "A purchase receipt increases stock. If it posts no stock movement, it is paperwork, not a receipt.",
        "Received quantity is a physical fact and must reflect what actually arrived, even when that differs from what was ordered or later invoiced.",
        "A receipt creates no payable. The supplier's invoice does that, and the two are deliberately separate events."
      ],
      "commonMistakes": [
        {
          "mistake": "Receiving against the purchase order quantity rather than the physical count",
          "why": "It makes the three-way match meaningless. The system then agrees with the order and the invoice while disagreeing with the warehouse, and the discrepancy only surfaces at stock-take — months later, with no way to attribute it."
        },
        {
          "mistake": "Skipping the receipt and booking stock straight from the supplier invoice",
          "why": "Stock then arrives on the accounting date rather than the physical date, and goods received but not yet invoiced become invisible. That gap is where most year-end accrual errors live."
        },
        {
          "mistake": "Accepting over-receipt silently because the tolerance field allows it",
          "why": "A tolerance is a decision about which commodities may legitimately arrive over, not a global convenience. Applied everywhere, it is an open door — the supplier ships more, the system accepts it, and nobody approved the extra spend."
        }
      ],
      "edgeCases": [
        "Goods received and rejected at inspection — the movement happened and needs a return, not a deletion.",
        "Partial receipt across several deliveries against one order line, where the balance may no longer be wanted by the time it arrives.",
        "Goods received without paperwork, which the warehouse must still be able to record — an unrecorded arrival is worse than an imperfect one.",
        "Subcontracting receipts, where finished goods arrive and your own raw material is consumed at someone else's site.",
        "Landed costs — freight and duty that belong in the item's valuation but arrive on a different document, days later."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Purchase Receipt",
            "note": "Submitting posts Stock Ledger Entries and credits Stock Received But Not Billed — the accrual that makes the gap visible."
          },
          {
            "doctype": "Stock Ledger Entry",
            "note": "Immutable. Corrections are new entries, never edits."
          },
          {
            "doctype": "Purchase Invoice",
            "note": "Created from the receipt, which is what keeps received and billed quantities aligned."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "purchase-invoice",
      "title": "Purchase Invoice",
      "domain": "Procurement",
      "url": "https://mith.tech/concepts/purchase-invoice",
      "definition": "A purchase invoice is a supplier's demand for payment that creates a liability in the buyer's accounts.",
      "aliases": [
        "Bill",
        "Vendor invoice",
        "Payable",
        "AP invoice"
      ],
      "relationships": [
        {
          "predicate": "issuedBy",
          "target": "supplier"
        },
        {
          "predicate": "bills",
          "target": "purchase-order"
        },
        {
          "predicate": "matchedAgainst",
          "target": "purchase-receipt"
        },
        {
          "predicate": "settledBy",
          "target": "payment"
        },
        {
          "predicate": "posts",
          "target": "general-ledger"
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Recorded, not posted. No liability."
        },
        {
          "state": "Submitted",
          "meaning": "Posted. Payable created, input tax recorded."
        },
        {
          "state": "Matched",
          "meaning": "Reconciled against order and receipt; cleared for payment."
        },
        {
          "state": "Partly paid",
          "meaning": "One or more payments applied; a balance remains."
        },
        {
          "state": "Paid",
          "meaning": "Outstanding is zero."
        },
        {
          "state": "Cancelled",
          "meaning": "Reversed with an equal and opposite entry, the document retained."
        }
      ],
      "invariants": [
        "A purchase invoice creates a payable and posts to the ledger; an unposted one is a draft, not a liability.",
        "It must be matched against what was ordered and what was received before payment — the three-way match is a control, not a formality.",
        "Input tax credit may only be claimed where the supplier's GSTIN is valid and the supplier has actually filed. Your record being correct is not sufficient."
      ],
      "commonMistakes": [
        {
          "mistake": "Paying from the invoice alone, without matching to receipt",
          "why": "You pay for what the supplier says they sent rather than what arrived. This is the single most common route for both honest billing errors and deliberate over-invoicing, and it is invisible in the accounts because the invoice and the payment agree perfectly."
        },
        {
          "mistake": "Claiming input tax credit as soon as the invoice is booked",
          "why": "Under GST the credit depends on the supplier filing their return. Booking it early inflates the credit and produces a reversal — with interest — when the reconciliation runs."
        },
        {
          "mistake": "Treating a price difference as an approval problem rather than a decision",
          "why": "When the invoice price differs from the order, someone has to decide whether to accept it. A rule cannot make that call; routing it to a human who knows the commercial context is the whole point of the exception."
        }
      ],
      "edgeCases": [
        "Invoice arriving before the goods, common with imports, where the payable exists and the stock does not.",
        "Supplier invoicing in a different currency from the order, where the exchange difference belongs to settlement rather than to cost.",
        "Landed costs invoiced separately by a third party — freight forwarder, customs agent — that must still land in the item's valuation.",
        "Credit notes from a supplier for short supply or quality, which reduce the payable and may need to reverse input tax already claimed.",
        "Services with no receipt at all, where the invoice is the only evidence the work happened and approval replaces the match."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Purchase Invoice",
            "note": "`docstatus` 0/1/2 as elsewhere. Setting `update_stock` makes it move stock too — correct only when there is genuinely no separate receipt."
          },
          {
            "doctype": "Purchase Receipt",
            "note": "Linked so received and billed quantities reconcile. Skipping the link is what breaks the match."
          },
          {
            "doctype": "GL Entry",
            "note": "Clears Stock Received But Not Billed against the payable — which is why an unmatched receipt leaves that account growing."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "general-ledger",
      "title": "General Ledger",
      "domain": "Finance",
      "url": "https://mith.tech/concepts/general-ledger",
      "definition": "The general ledger is the complete, permanent record of every financial transaction a business has posted, organised by account.",
      "aliases": [
        "GL",
        "Nominal ledger",
        "Books of account",
        "The ledger"
      ],
      "relationships": [
        {
          "predicate": "receivesFrom",
          "target": "invoice",
          "note": "Revenue and receivable."
        },
        {
          "predicate": "receivesFrom",
          "target": "payment",
          "note": "Cash and settlement."
        },
        {
          "predicate": "receivesFrom",
          "target": "purchase-invoice",
          "note": "Expense and payable."
        },
        {
          "predicate": "receivesFrom",
          "target": "delivery-note",
          "note": "Cost of goods sold."
        },
        {
          "predicate": "organisedBy",
          "target": "chart-of-accounts"
        }
      ],
      "lifecycle": [
        {
          "state": "Open period",
          "meaning": "Entries may be posted. Balances still moving."
        },
        {
          "state": "Soft close",
          "meaning": "Operational posting stopped; adjustments still permitted while review runs."
        },
        {
          "state": "Closed",
          "meaning": "No further entries. Balances final and reportable."
        },
        {
          "state": "Locked",
          "meaning": "Period frozen after filing or audit. Reopening is an explicit, logged decision."
        }
      ],
      "invariants": [
        "Every entry must balance: total debits equal total credits, always, with no rounding plug.",
        "A posted entry is immutable. Corrections are new, opposite entries — never edits.",
        "Every entry carries a date, an account, an amount and a reference to the document that created it. An entry you cannot trace to a source document is unexplained.",
        "The ledger is the single source of financial truth. When a sub-ledger and the general ledger disagree, one of them is wrong and it is usually not the ledger."
      ],
      "commonMistakes": [
        {
          "mistake": "Posting adjusting entries directly to the ledger to make a sub-ledger agree",
          "why": "It makes the totals match while destroying the explanation. The receivables control account now equals the receivables list, and neither tells you which customer the difference belonged to."
        },
        {
          "mistake": "Backdating entries into a closed period",
          "why": "Financials already reported change retrospectively. Anyone comparing this month's opening balance to last month's closing finds they no longer agree, and there is nothing in the system that says why."
        },
        {
          "mistake": "Treating the ledger as something only accountants touch",
          "why": "Almost every ledger entry is created by an operational document — an invoice, a delivery, a payment. Operational mistakes become accounting mistakes automatically, which is why fixing the ledger without fixing the process only buys a month."
        }
      ],
      "edgeCases": [
        "Multi-currency, where the ledger holds both the transaction currency and the reporting currency, and revaluation moves one without the other.",
        "Inter-company transactions, which must eliminate on consolidation but stay visible in each entity's own books.",
        "Period-end accruals reversed automatically in the next period — correct, and a frequent source of confusion when someone sees the reversal in isolation.",
        "Opening balances at migration, which arrive as a journal entry with no operational document behind them and therefore need unusually good narration."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "GL Entry",
            "note": "Written on submit of any financial document. Never created or edited by hand in a healthy system."
          },
          {
            "doctype": "Journal Entry",
            "note": "The one place manual entries belong — accruals, provisions, set-off, corrections. Every one should have a narration explaining itself."
          },
          {
            "doctype": "Account",
            "note": "The chart. `is_group` distinguishes headings from postable accounts; posting to a group account is a common and confusing misconfiguration."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "item",
      "title": "Item",
      "domain": "Inventory",
      "url": "https://mith.tech/concepts/item",
      "definition": "An item is a distinct good or service that a business buys, sells, stocks or manufactures, identified by a unique code.",
      "aliases": [
        "Product",
        "SKU",
        "Material",
        "Article",
        "Part"
      ],
      "relationships": [
        {
          "predicate": "soldVia",
          "target": "sales-order"
        },
        {
          "predicate": "purchasedVia",
          "target": "purchase-order"
        },
        {
          "predicate": "storedIn",
          "target": "warehouse"
        },
        {
          "predicate": "movedBy",
          "target": "delivery-note",
          "note": "And by purchase receipts, in the other direction."
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Being defined. Not transactable."
        },
        {
          "state": "Active",
          "meaning": "Available to buy, sell or stock."
        },
        {
          "state": "End of life",
          "meaning": "No new purchasing; existing stock still sells down."
        },
        {
          "state": "Disabled",
          "meaning": "No transactions. History retained and the code never reused."
        }
      ],
      "invariants": [
        "An item code is unique and permanent. Reusing a retired code makes every historical report about that code ambiguous.",
        "An item is either stocked or it is not, and that decision determines whether it has a stock ledger at all.",
        "Unit of measure is intrinsic to the item. Changing it after transactions exist invalidates every quantity previously recorded."
      ],
      "commonMistakes": [
        {
          "mistake": "Encoding meaning in the item code",
          "why": "A code like RM-STL-10MM-BLR reads well until steel moves warehouse or the grade changes. Attributes belong in fields that can be filtered and changed; the code should be an identifier and nothing else."
        },
        {
          "mistake": "Creating separate items for what are really variants",
          "why": "The same shirt in four sizes as four items means stock, pricing and reporting cannot roll up. The same shirt as one item with a size attribute means it can. Getting this wrong is very expensive to reverse."
        },
        {
          "mistake": "Changing unit of measure on a live item",
          "why": "Every historical quantity silently changes meaning. A hundred 'boxes' becomes a hundred 'pieces' across years of transactions, and no report will flag it."
        }
      ],
      "edgeCases": [
        "Items that are sometimes stocked and sometimes drop-shipped, where the same code has a stock ledger for one flow and not the other.",
        "Batch- or serial-tracked items, where identity is per-unit rather than per-code and quantity alone is insufficient.",
        "Service items with no stock at all, which still need pricing, tax treatment and an HSN/SAC code.",
        "Items whose specification changes while the code stays — a supplier reformulation that nobody records is invisible until a customer notices."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Item",
            "note": "`is_stock_item` decides whether a stock ledger exists at all — the single most consequential flag on the record."
          },
          {
            "doctype": "Item Variant",
            "note": "Attribute-driven variants of a template. The correct answer to size/colour, and to most 'we need 40 similar items' requests."
          },
          {
            "doctype": "UOM Conversion Detail",
            "note": "Lets an item be bought in cartons and sold in pieces without two item records."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "gstin",
      "title": "GSTIN",
      "domain": "Systems",
      "url": "https://mith.tech/concepts/gstin",
      "definition": "A GSTIN is a 15-character registration number issued to a business for a specific Indian state, under which that business collects and remits GST for operations in that state.",
      "aliases": [
        "GST number",
        "GST registration",
        "Tax registration"
      ],
      "relationships": [
        {
          "predicate": "belongsTo",
          "target": "company"
        },
        {
          "predicate": "appliesTo",
          "target": "invoice",
          "note": "Determines the tax treatment of every line."
        },
        {
          "predicate": "constrains",
          "target": "warehouse",
          "note": "A warehouse sits in a state and therefore under a registration."
        },
        {
          "predicate": "governs",
          "target": "tax-rule"
        }
      ],
      "lifecycle": [
        {
          "state": "Applied",
          "meaning": "Registration submitted, not yet granted. Cannot be used on invoices."
        },
        {
          "state": "Active",
          "meaning": "Granted. Collects tax, files returns, claims credit."
        },
        {
          "state": "Suspended",
          "meaning": "Filing lapsed or under scrutiny. Counterparties' credit is at risk."
        },
        {
          "state": "Cancelled",
          "meaning": "Surrendered or revoked. Historical transactions remain and still need reconciling."
        }
      ],
      "invariants": [
        "A GSTIN is per state, not per company. One legal entity operating in four states holds four GSTINs.",
        "Each GSTIN files its own returns, holds its own input tax credit, and reconciles independently — credit does not pool across registrations.",
        "The first two characters are the state code and characters 3–12 are the entity's PAN, so a GSTIN and a PAN are structurally related but not interchangeable.",
        "A transaction's place of supply, not the seller's address, determines whether CGST+SGST or IGST applies."
      ],
      "commonMistakes": [
        {
          "mistake": "Modelling a multi-state business as one company with a single GSTIN field",
          "why": "The commonest structural error in Indian ERP work. Returns cannot be filed per registration, credit pools that must stay separate get merged, and the fix after go-live means restating every transaction by state."
        },
        {
          "mistake": "Treating a branch as a GSTIN, or a GSTIN as a branch",
          "why": "They are different axes. Two branches in one state share a GSTIN; one branch may serve two states. Conflating them breaks either the tax treatment or the operational reporting, usually both."
        },
        {
          "mistake": "Assuming stock transfers between own locations are tax-free",
          "why": "A movement between two GSTINs of the SAME company is a taxable supply under GST and needs an invoice. Businesses discover this when a consignment is stopped, not when the stock moves."
        },
        {
          "mistake": "Claiming input credit without checking the supplier filed",
          "why": "The credit depends on the supplier's GSTR-1, not on holding their invoice. Reconciliation against the portal is a recurring operational task; skipping it produces reversals with interest."
        }
      ],
      "edgeCases": [
        "SEZ units, where supplies are zero-rated and the normal intra-state logic does not apply.",
        "Composition-scheme suppliers, who cannot pass on input credit — buying from them changes your effective cost, not just your paperwork.",
        "Reverse charge, where the buyer remits tax the supplier would normally collect.",
        "Bill-to and ship-to in different states, where place of supply follows a specific statutory rule rather than intuition.",
        "A customer whose GSTIN is cancelled mid-relationship, invalidating credit on invoices already booked."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Company",
            "note": "Holds the PAN. Multi-state operations are usually separate Companies or separate Address records carrying their own GSTIN."
          },
          {
            "doctype": "Address",
            "note": "`gstin` and `gst_state` live here — which is why place of supply derives from the address on the transaction, not from a company setting."
          },
          {
            "doctype": "Tax Category / GST Settings",
            "note": "Drives whether CGST+SGST or IGST applies. Misconfigured, the whole return is wrong rather than one invoice."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "warehouse",
      "title": "Warehouse",
      "domain": "Inventory",
      "url": "https://mith.tech/concepts/warehouse",
      "definition": "A warehouse is a defined location at which stock is held and against which stock movements are recorded.",
      "aliases": [
        "Location",
        "Store",
        "Godown",
        "Stock location",
        "Site"
      ],
      "relationships": [
        {
          "predicate": "holds",
          "target": "item"
        },
        {
          "predicate": "receivesFrom",
          "target": "purchase-receipt"
        },
        {
          "predicate": "issuesVia",
          "target": "delivery-note"
        },
        {
          "predicate": "governedBy",
          "target": "gstin",
          "note": "Its state decides the registration movements fall under."
        }
      ],
      "lifecycle": [
        {
          "state": "Planned",
          "meaning": "Defined, not yet operational. No stock."
        },
        {
          "state": "Active",
          "meaning": "Receiving and issuing stock."
        },
        {
          "state": "Frozen",
          "meaning": "No movements permitted — stock-take, audit or dispute."
        },
        {
          "state": "Closed",
          "meaning": "Emptied and retired. History retained; the record is never deleted."
        }
      ],
      "invariants": [
        "Stock always sits in exactly one warehouse. Quantity without a location is not stock, it is a rumour.",
        "A warehouse has a physical address, and in India that address determines which GSTIN governs movements in and out of it.",
        "Moving stock between warehouses is a transaction, not an edit — even when both belong to the same company."
      ],
      "commonMistakes": [
        {
          "mistake": "Making the warehouse hierarchy too granular",
          "why": "Rack-and-bin-level warehouses mean every stock entry needs a location decision nobody has time to make. Staff post to a default, the detail becomes fiction, and precision is lost that coarser tracking would have kept honest."
        },
        {
          "mistake": "Making it too coarse",
          "why": "One warehouse for three physical sites means the system can say how much exists but not where. Every picking decision then needs a phone call, which is the problem the system was bought to remove."
        },
        {
          "mistake": "Using warehouses to represent stock status rather than place",
          "why": "A 'Damaged' or 'In transit' warehouse is a state pretending to be a location. It works until you need to know which physical site the damaged stock is actually sitting in — and then nothing can answer."
        }
      ],
      "edgeCases": [
        "Stock in transit between two of your own warehouses — owned by you, present in neither, and invisible unless modelled.",
        "Consignment stock at a customer site, which you own but do not hold.",
        "Third-party logistics warehouses, where the location is real but the operator is not you.",
        "Warehouses in different states, where an internal transfer becomes a taxable supply requiring an invoice and an e-way bill."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Warehouse",
            "note": "Tree-structured. `is_group` nodes are for rollup and cannot hold stock — posting to one is a frequent misconfiguration."
          },
          {
            "doctype": "Bin",
            "note": "The item-warehouse pair holding actual, reserved and ordered quantity. This is where 'available' is really computed."
          },
          {
            "doctype": "Stock Ledger Entry",
            "note": "Every movement in or out. Immutable; corrections are new entries."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "company",
      "title": "Company",
      "domain": "Systems",
      "url": "https://mith.tech/concepts/company",
      "definition": "A company is a legal entity that owns assets, incurs liabilities, files its own statutory accounts, and under which all transactions of a business unit are recorded.",
      "aliases": [
        "Legal entity",
        "Entity",
        "Firm",
        "Books"
      ],
      "relationships": [
        {
          "predicate": "holds",
          "target": "gstin",
          "note": "One per state of operation."
        },
        {
          "predicate": "owns",
          "target": "warehouse"
        },
        {
          "predicate": "maintains",
          "target": "general-ledger",
          "note": "One complete set of books per company."
        },
        {
          "predicate": "transactsWith",
          "target": "customer"
        }
      ],
      "lifecycle": [
        {
          "state": "Incorporated",
          "meaning": "Legally formed. May not yet trade."
        },
        {
          "state": "Active",
          "meaning": "Trading, filing, maintaining books."
        },
        {
          "state": "Dormant",
          "meaning": "No trading activity, but still filing. Books stay open."
        },
        {
          "state": "Struck off / dissolved",
          "meaning": "No longer exists. Records retained for the statutory period."
        }
      ],
      "invariants": [
        "Each company keeps its own complete set of books. A trial balance belongs to exactly one company.",
        "Transactions between two companies are real transactions, even under common ownership — they invoice each other and eliminate only on consolidation.",
        "A company holds one PAN. Its GST registrations are per state and hang beneath it, not beside it."
      ],
      "commonMistakes": [
        {
          "mistake": "Modelling branches or divisions as separate companies",
          "why": "It forces inter-company invoicing for what is internally a transfer, multiplies the closing work by the number of 'companies', and produces consolidated accounts nobody asked for. Branches are a dimension within one company, not entities."
        },
        {
          "mistake": "Modelling genuinely separate legal entities as one company with a dimension",
          "why": "The opposite error, and worse. Statutory accounts cannot be produced per entity, the tax position is unfilable, and unwinding it means restating every transaction."
        },
        {
          "mistake": "Deciding the structure during configuration rather than discovery",
          "why": "It is the decision every other structural choice depends on — chart of accounts, warehouses, registrations, permissions. Changing it after go-live is the most expensive rework available in an implementation."
        }
      ],
      "edgeCases": [
        "Group structures where a holding company owns several trading entities and consolidation is a genuine requirement rather than a preference.",
        "The same trading name operating under two entities — customers see one brand, the books see two.",
        "Mid-year restructures, where transactions before and after belong to different entities and comparatives stop being comparable.",
        "Foreign subsidiaries, where functional and reporting currency differ and translation is a period-end process rather than a field."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Company",
            "note": "Holds PAN, currency and the chart of accounts. Each company gets its own account tree — accounts are not shared."
          },
          {
            "doctype": "Cost Center",
            "note": "The correct home for branches and divisions inside one company. This is the answer to most 'should this be a company?' questions."
          },
          {
            "doctype": "Party Account",
            "note": "Where a customer or supplier's control account is set per company, which is what keeps books separate under common ownership."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "tax-rule",
      "title": "Tax Rule",
      "domain": "Systems",
      "url": "https://mith.tech/concepts/tax-rule",
      "definition": "A tax rule is the logic that determines which tax rates apply to a transaction, based on what is being sold, who is buying, and where the supply takes place.",
      "aliases": [
        "Tax template",
        "Tax category",
        "Tax configuration",
        "Rate determination"
      ],
      "relationships": [
        {
          "predicate": "governedBy",
          "target": "gstin"
        },
        {
          "predicate": "appliesTo",
          "target": "invoice"
        },
        {
          "predicate": "classifiedBy",
          "target": "item",
          "note": "HSN or SAC drives the rate."
        },
        {
          "predicate": "dependsOn",
          "target": "customer",
          "note": "Registration status and place of supply."
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Configured, not yet in effect."
        },
        {
          "state": "Effective",
          "meaning": "In force from its start date. Applies to new transactions."
        },
        {
          "state": "Superseded",
          "meaning": "Replaced by a later rule. Retained so historical transactions still explain themselves."
        }
      ],
      "invariants": [
        "Tax is determined by the transaction, not chosen by the user. A rate someone types in is a data-entry decision masquerading as a tax position.",
        "The determination depends on at least three inputs: the item's classification, the counterparty's status, and the place of supply.",
        "A tax rule change applies from a date forward. Retroactively editing a rule silently restates transactions already filed."
      ],
      "commonMistakes": [
        {
          "mistake": "Letting users pick the tax template on the transaction",
          "why": "It works until someone picks wrong, and nothing catches it because the invoice is internally consistent. Determination should be derived from the item, the party and the place of supply — and only overridden with a reason."
        },
        {
          "mistake": "Encoding the rate rather than the rule",
          "why": "Rates change by statute. A system holding 18% as a number needs editing everywhere when it moves; a system holding 'this HSN, this place of supply' needs one rate updated in one place."
        },
        {
          "mistake": "Ignoring place of supply because most business is local",
          "why": "It is right until the first inter-state sale, which then carries CGST+SGST where IGST was due. The error is invisible on the invoice and surfaces at return filing, applied to every transaction since."
        },
        {
          "mistake": "Treating exemptions as a zero rate",
          "why": "Zero-rated, exempt and nil-rated are three different things with three different reporting treatments and different effects on input credit. Collapsing them makes the return wrong even when the tax collected is right."
        }
      ],
      "edgeCases": [
        "Reverse charge, where the buyer remits tax the supplier would normally collect and the invoice shows no tax at all.",
        "Composition-scheme suppliers, who charge no GST and pass on no credit — your cost is the full invoice.",
        "Exports and SEZ supplies, zero-rated with or without payment of tax, each with a different refund path.",
        "Mid-year statutory rate changes, where the applicable rate depends on the transaction date rather than the posting date.",
        "Bill-to and ship-to in different states, where place of supply follows a specific rule rather than the delivery address."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Tax Rule",
            "note": "Maps party, item group and place of supply to a template. This is the determination layer that stops users choosing."
          },
          {
            "doctype": "Sales Taxes and Charges Template",
            "note": "The rate set itself. Referenced by rules rather than selected on transactions."
          },
          {
            "doctype": "Item Tax Template",
            "note": "Item-level overrides for goods taxed differently from their group — the exception mechanism."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "quotation",
      "title": "Quotation",
      "domain": "Sales",
      "url": "https://mith.tech/concepts/quotation",
      "definition": "A quotation is a seller's formal offer to supply specified goods or services at stated prices, valid for a stated period.",
      "aliases": [
        "Quote",
        "Estimate",
        "Proposal",
        "Bid",
        "Offer"
      ],
      "relationships": [
        {
          "predicate": "offeredTo",
          "target": "customer"
        },
        {
          "predicate": "prices",
          "target": "item"
        },
        {
          "predicate": "becomes",
          "target": "sales-order",
          "note": "On acceptance. The commitment starts there, not here."
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Being prepared. Not seen by the customer."
        },
        {
          "state": "Sent",
          "meaning": "Issued. A live offer, binding on the seller until expiry."
        },
        {
          "state": "Revised",
          "meaning": "Superseded by a later version. The prior version is retained."
        },
        {
          "state": "Accepted",
          "meaning": "Converted to a sales order. Commitment begins."
        },
        {
          "state": "Lost / expired",
          "meaning": "Closed unaccepted. The reason is the useful part."
        }
      ],
      "invariants": [
        "A quotation has an expiry. An offer with no validity period is a price the seller cannot withdraw.",
        "It commits nothing — no stock, no capacity, no revenue — until it is accepted and becomes an order.",
        "The version a customer accepted must remain retrievable. Overwriting a quotation destroys the evidence of what was actually offered."
      ],
      "commonMistakes": [
        {
          "mistake": "Editing a sent quotation in place when the customer asks for changes",
          "why": "You lose the record of what was originally offered, which is exactly the document a disputed order turns on. Revisions should be versions, not overwrites."
        },
        {
          "mistake": "Quoting without checking availability or lead time",
          "why": "The date on the quote becomes a commitment the moment it is accepted. Quoting from optimism rather than from the system is how a sales team sells a delivery the warehouse cannot make."
        },
        {
          "mistake": "Letting quotations sit open indefinitely",
          "why": "The pipeline fills with offers nobody will accept, forecasting becomes fiction, and old prices stay technically live. An expiry is a data-hygiene mechanism as much as a commercial one."
        }
      ],
      "edgeCases": [
        "Quotes with volume-tiered pricing, where accepting a lower quantity invalidates the rate quoted.",
        "Long-validity quotes in a volatile input market, where honouring the price destroys the margin.",
        "Partial acceptance — the customer wants three of five lines, which is a new offer rather than a partial one.",
        "Quotes issued in a currency that has moved by acceptance, where the exchange risk sat with the seller for the whole validity window."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Quotation",
            "note": "`valid_till` drives expiry. `status` moves to Ordered on conversion rather than being set by hand."
          },
          {
            "doctype": "Sales Order",
            "note": "Created from the quotation, which is what preserves the link between what was offered and what was sold."
          },
          {
            "doctype": "Opportunity",
            "note": "Sits upstream. A quotation is the priced offer; the opportunity is the pursuit."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "return",
      "title": "Return",
      "domain": "Inventory",
      "url": "https://mith.tech/concepts/return",
      "definition": "A return is the movement of goods back from a buyer to a seller, reversing all or part of a completed delivery.",
      "aliases": [
        "Sales return",
        "Purchase return",
        "RMA",
        "Goods return",
        "Reverse logistics"
      ],
      "relationships": [
        {
          "predicate": "reverses",
          "target": "delivery-note"
        },
        {
          "predicate": "triggers",
          "target": "credit-note",
          "note": "Usually — but not every return earns a full credit."
        },
        {
          "predicate": "increases",
          "target": "warehouse",
          "note": "Into a quarantine or returns location, not straight to sellable."
        },
        {
          "predicate": "concerns",
          "target": "item"
        }
      ],
      "lifecycle": [
        {
          "state": "Requested",
          "meaning": "Customer has asked to return. Nothing has moved."
        },
        {
          "state": "Authorised",
          "meaning": "Approved, terms agreed. The customer may ship."
        },
        {
          "state": "Received",
          "meaning": "Goods physically back. Stock increases in a returns location."
        },
        {
          "state": "Inspected",
          "meaning": "Condition assessed. Determines whether it is resellable, repairable or scrap."
        },
        {
          "state": "Settled",
          "meaning": "Credit issued, replacement sent, or claim rejected."
        }
      ],
      "invariants": [
        "A return moves stock and adjusts money, and the two are separate decisions — goods can come back without a full refund, and a credit can be issued without goods returning.",
        "Returned stock must land in a known condition state. Putting damaged goods back into sellable inventory is how a return becomes a second complaint.",
        "A return references the original delivery or invoice. One that references nothing is an unexplained stock increase."
      ],
      "commonMistakes": [
        {
          "mistake": "Issuing a credit note without reversing the stock",
          "why": "The money goes back and the goods do not exist in the system. Inventory overstates by exactly the returned quantity and the gap compounds silently with every return."
        },
        {
          "mistake": "Returning stock straight to the sellable bin without inspection",
          "why": "You resell the item that came back for a reason. The customer-facing cost of that is much higher than the handling cost of a quarantine step."
        },
        {
          "mistake": "Modelling returns as negative sales",
          "why": "It nets out in revenue and destroys the ability to measure return rate, which is the actual signal. A 20% return rate and a 20% discount look identical in a net-revenue report and mean entirely different things."
        },
        {
          "mistake": "Not recording the reason",
          "why": "Returns are the cheapest quality data a business has. Without a reason code they are a cost; with one they are a defect report from a customer who bothered to send it back."
        }
      ],
      "edgeCases": [
        "Return of an item whose price has since changed — credit at the original price, not the current one.",
        "Partial return where the credit is not proportional, because the reason is damage rather than rejection.",
        "Returns after the GST credit-note window has closed, where the tax cannot be recovered even though the goods came back.",
        "Customer returns something never sold to them, which is a receiving problem rather than a returns one.",
        "Returned goods that go to scrap — stock increases and immediately decreases, and both movements need recording."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Delivery Note",
            "note": "With `is_return` = 1. A return is a negative delivery note, which is what keeps the stock reversal linked to the original movement."
          },
          {
            "doctype": "Sales Invoice",
            "note": "With `is_return` = 1 for the credit side. Stock and money are separate documents on purpose."
          },
          {
            "doctype": "Warehouse",
            "note": "A dedicated returns/quarantine warehouse is the mechanism that stops uninspected stock being sold again."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "approval-workflow",
      "title": "Approval Workflow",
      "domain": "Systems",
      "url": "https://mith.tech/concepts/approval-workflow",
      "definition": "An approval workflow is a defined sequence of authorisations a document must obtain before it becomes binding or actionable.",
      "aliases": [
        "Authorisation",
        "Sign-off",
        "Approval matrix",
        "Delegation of authority"
      ],
      "relationships": [
        {
          "predicate": "gates",
          "target": "purchase-order",
          "note": "The commonest application: authorising spend before it is committed."
        },
        {
          "predicate": "gates",
          "target": "invoice",
          "note": "Credit notes and write-offs especially."
        },
        {
          "predicate": "assignedTo",
          "target": "employee"
        },
        {
          "predicate": "recordedIn",
          "target": "general-ledger",
          "note": "Indirectly — the approval is the reason the entry was permitted."
        }
      ],
      "lifecycle": [
        {
          "state": "Draft",
          "meaning": "Being prepared. Not submitted, not binding."
        },
        {
          "state": "Pending",
          "meaning": "Awaiting a decision at the current level."
        },
        {
          "state": "Approved",
          "meaning": "All required authorisations obtained. The document may act."
        },
        {
          "state": "Rejected",
          "meaning": "Declined with a reason. Returns to the requester rather than vanishing."
        },
        {
          "state": "Escalated",
          "meaning": "Passed up after timeout or because it exceeds the current level's authority."
        }
      ],
      "invariants": [
        "An approver must be able to reject, not only approve. A step with no possible outcome but yes is a notification wearing a control's clothes.",
        "The approver must be a different person from the requester. Self-approval defeats the entire mechanism.",
        "Every decision is recorded with who, when and — for rejections — why. An approval you cannot attribute is not evidence of anything.",
        "A document in flight is not yet binding. It commits nothing until the last required approval lands."
      ],
      "commonMistakes": [
        {
          "mistake": "Routing approvals by org chart rather than by knowledge",
          "why": "The person senior enough to approve is often too far from the work to judge it. They approve everything, the control becomes a rubber stamp, and its existence provides false assurance — worse than no control, because everyone believes it is working."
        },
        {
          "mistake": "Too many steps",
          "why": "Every step adds delay, and delay is what makes people route around the system entirely. Orders get placed by phone and the paperwork raised afterwards, which converts a control into a formality applied to decisions already made."
        },
        {
          "mistake": "No delegation path for absence",
          "why": "One person on leave halts every approval at their level. Teams solve it by sharing credentials, which destroys attribution — and attribution was most of the value."
        },
        {
          "mistake": "Thresholds that never change",
          "why": "A ₹50,000 limit set in 2015 routes trivia to a director by 2026. Limits need periodic review or the workflow silently reweights itself toward noise."
        }
      ],
      "edgeCases": [
        "Emergency purchases where the goods are needed before anyone can approve, which needs a defined retrospective path rather than an undefined one.",
        "An approver who is also the requester on their own department's spend.",
        "Documents amended after approval — whether that voids the approval is a policy decision the system must encode, not infer.",
        "Approval thresholds in a foreign currency, where the limit is breached or not depending on the day's rate."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Workflow",
            "note": "States and transitions per doctype. `allow_self_approval` should be off for anything financial."
          },
          {
            "doctype": "Authorization Rule",
            "note": "Value-based thresholds — the mechanism for 'over this amount, a different person decides'."
          },
          {
            "doctype": "Workflow Action",
            "note": "The audit trail: who acted, when, and the comment. This is the artefact an auditor actually asks for."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "chart-of-accounts",
      "title": "Chart of Accounts",
      "domain": "Finance",
      "url": "https://mith.tech/concepts/chart-of-accounts",
      "definition": "A chart of accounts is the structured list of every account against which a business records financial transactions.",
      "aliases": [
        "CoA",
        "Account tree",
        "Account master",
        "Ledger structure"
      ],
      "relationships": [
        {
          "predicate": "organises",
          "target": "general-ledger"
        },
        {
          "predicate": "belongsTo",
          "target": "company",
          "note": "One chart per company; accounts are not shared between entities."
        },
        {
          "predicate": "receivesFrom",
          "target": "invoice"
        },
        {
          "predicate": "constrainedBy",
          "target": "tax-rule",
          "note": "Tax accounts must exist at the granularity the return requires."
        }
      ],
      "lifecycle": [
        {
          "state": "Designed",
          "meaning": "Structure agreed against the reports it must produce."
        },
        {
          "state": "Active",
          "meaning": "In use. Receiving postings."
        },
        {
          "state": "Disabled",
          "meaning": "No new postings. History intact and still reportable."
        }
      ],
      "invariants": [
        "Every postable account belongs to exactly one of asset, liability, equity, income or expense. That classification determines which statement it appears in and cannot be ambiguous.",
        "Group accounts organise; only leaf accounts receive postings. Posting to a group is a misconfiguration, not a shortcut.",
        "An account with transactions may be disabled but never deleted, and never repurposed — reusing a code makes every historical report about it ambiguous."
      ],
      "commonMistakes": [
        {
          "mistake": "Adding an account for every question someone might ask",
          "why": "A chart with 800 accounts means nobody can find the right one, postings land in approximations, and the detail everyone paid for turns into noise. If a data-entry clerk cannot choose without asking, there are too many."
        },
        {
          "mistake": "Using accounts where dimensions belong",
          "why": "Three product lines across four branches becomes twelve revenue accounts, and a fifth branch means creating three more. Accounts are for different accounting TREATMENT; cost centres and dimensions are for slicing."
        },
        {
          "mistake": "Not mapping to the statutory format up front",
          "why": "In India, financials must present per Schedule III. A chart that does not map cleanly means someone rebuilds the mapping by hand every year — and hand-built mappings are where errors hide."
        },
        {
          "mistake": "Collapsing GST accounts",
          "why": "CGST, SGST, IGST and cess each need separate accounts on both input and output sides. Merged, return filing stops being a report and becomes a reconstruction."
        }
      ],
      "edgeCases": [
        "Migrating from a flat chart, where a legacy code maps to two new accounts and the split needs a judgement per transaction.",
        "Multi-currency accounts, which hold a balance in both transaction and reporting currency and revalue independently.",
        "Control accounts for receivables and payables, which must reconcile to their sub-ledgers and should never be posted to directly.",
        "Charts inherited from an accountant's template that carry accounts for a business model this business does not have."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Account",
            "note": "Tree-structured. `is_group` separates headings from postable accounts; `root_type` sets the statement classification."
          },
          {
            "doctype": "Cost Center",
            "note": "The dimension axis. This is the answer to most 'we need more accounts' requests."
          },
          {
            "doctype": "Company",
            "note": "Owns the tree. Each company gets its own, which is what keeps books separate under common ownership."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "contact",
      "title": "Contact",
      "domain": "Sales",
      "url": "https://mith.tech/concepts/contact",
      "definition": "A contact is a person associated with one or more parties a business deals with, reachable by name and channel.",
      "aliases": [
        "Person",
        "Individual",
        "Point of contact",
        "Lead contact"
      ],
      "relationships": [
        {
          "predicate": "linkedTo",
          "target": "customer",
          "note": "Many-to-many, via a link table rather than a field."
        },
        {
          "predicate": "linkedTo",
          "target": "supplier"
        },
        {
          "predicate": "reachableAt",
          "target": "address"
        }
      ],
      "lifecycle": [
        {
          "state": "Active",
          "meaning": "Current and reachable."
        },
        {
          "state": "Moved",
          "meaning": "Left the party they were linked to. Retained; the link is closed rather than deleted."
        },
        {
          "state": "Unsubscribed",
          "meaning": "Withdrew consent for one or more channels. Still transactable, not marketable."
        },
        {
          "state": "Inactive",
          "meaning": "No longer contacted. History retained."
        }
      ],
      "invariants": [
        "A contact is a PERSON. A customer is a billing party. Conflating them breaks the moment one person buys for two companies, or one company has four buyers.",
        "A contact may be linked to several parties, and a party to several contacts. The relationship is many-to-many, not a field.",
        "Consent and contact preference belong on the contact, not on the party — a person's opt-out follows the person."
      ],
      "commonMistakes": [
        {
          "mistake": "Storing the contact as fields on the customer record",
          "why": "One phone number and one email per company works until the buyer, the accounts payable clerk and the site manager are three different people who need three different messages. Flattening loses all of that and cannot be undone from the data."
        },
        {
          "mistake": "Losing the contact when a person changes employer",
          "why": "The relationship is with the person as much as the company. Overwriting the record when they move destroys the history and the reason they answer your call."
        },
        {
          "mistake": "Treating a role as a contact",
          "why": "\"Accounts\" or \"Purchasing\" as a contact name means nobody is accountable, nobody has consented, and the address survives every staff change without anyone checking whether it still reaches a human."
        }
      ],
      "edgeCases": [
        "A person who is a contact at a customer AND a supplier — one record, two links, and any conflict of interest is a human judgement.",
        "Shared mailboxes that are genuinely the right destination for invoices, where a role-based address is correct and consent does not apply.",
        "Contacts who leave mid-project, taking the working relationship and the undocumented context with them."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Contact",
            "note": "Linked to parties via Dynamic Link child rows — which is exactly what makes the many-to-many work."
          },
          {
            "doctype": "Contact Email / Contact Phone",
            "note": "Child tables, because a person legitimately has several of each with one primary."
          },
          {
            "doctype": "Dynamic Link",
            "note": "The join. One contact row can serve a Customer, a Supplier and a Lead simultaneously."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "address",
      "title": "Address",
      "domain": "Sales",
      "url": "https://mith.tech/concepts/address",
      "definition": "An address is a physical or registered location associated with a party, used for delivery, billing or statutory identification.",
      "aliases": [
        "Location",
        "Billing address",
        "Shipping address",
        "Registered office"
      ],
      "relationships": [
        {
          "predicate": "belongsTo",
          "target": "customer"
        },
        {
          "predicate": "belongsTo",
          "target": "supplier"
        },
        {
          "predicate": "determines",
          "target": "tax-rule",
          "note": "Via place of supply."
        },
        {
          "predicate": "locates",
          "target": "warehouse"
        }
      ],
      "lifecycle": [
        {
          "state": "Active",
          "meaning": "In use for its stated purpose."
        },
        {
          "state": "Superseded",
          "meaning": "Replaced by a newer address. Retained so historical documents still explain themselves."
        },
        {
          "state": "Disabled",
          "meaning": "No longer used. Never deleted where documents reference it."
        }
      ],
      "invariants": [
        "A party may hold many addresses, and each has a purpose — billing, shipping, registered. One address serving all three is a coincidence, not a rule.",
        "In India the address carries the GSTIN and the state, which is why place of supply derives from it rather than from a company setting.",
        "Changing an address on a party must not retroactively alter documents already issued to the old one."
      ],
      "commonMistakes": [
        {
          "mistake": "One address field on the customer",
          "why": "Billing and shipping diverge constantly — head office pays, sites receive. A single field forces staff to overwrite it per order, which corrupts both."
        },
        {
          "mistake": "Editing an address in place when a customer relocates",
          "why": "Invoices already issued now show an address the customer never had at the time. For GST documents that is a compliance problem, not a cosmetic one."
        },
        {
          "mistake": "Not capturing state separately from the free-text address",
          "why": "Place of supply is determined by state. Parsing it out of a text blob at return time is how businesses discover they applied the wrong tax across a quarter."
        }
      ],
      "edgeCases": [
        "Bill-to and ship-to in different states, where place of supply follows a statutory rule rather than the delivery address.",
        "Customers with a registered office they never operate from — correct for invoices, wrong for deliveries.",
        "Addresses shared by group companies at one premises, where the same physical location has two GSTINs.",
        "Export addresses with no Indian state at all, which the tax logic must handle rather than default."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Address",
            "note": "`is_primary_address` and `is_shipping_address` are separate flags on purpose — one address can be both, or neither."
          },
          {
            "doctype": "Dynamic Link",
            "note": "Same join as Contact, so one address can serve several parties (shared premises, group companies)."
          },
          {
            "doctype": "Address Template",
            "note": "Country-specific formatting. Matters more than it sounds for statutory documents."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "employee",
      "title": "Employee",
      "domain": "Systems",
      "url": "https://mith.tech/concepts/employee",
      "definition": "An employee is a person engaged by a business under a contract of employment, carrying a payroll identity and a set of system permissions.",
      "aliases": [
        "Staff",
        "Team member",
        "Personnel",
        "Worker"
      ],
      "relationships": [
        {
          "predicate": "approves",
          "target": "approval-workflow"
        },
        {
          "predicate": "employedBy",
          "target": "company"
        },
        {
          "predicate": "reachableAt",
          "target": "address"
        }
      ],
      "lifecycle": [
        {
          "state": "Onboarding",
          "meaning": "Contracted, not yet started. Records exist, access does not."
        },
        {
          "state": "Active",
          "meaning": "Employed. Payroll runs, permissions live."
        },
        {
          "state": "On leave",
          "meaning": "Employed but absent — the state approval delegation must handle."
        },
        {
          "state": "Left",
          "meaning": "Employment ended. Access revoked, record retained, history intact."
        }
      ],
      "invariants": [
        "An employee record and a system user are different objects. Not every employee needs a login, and some system users are not employees.",
        "Employment has a start date and may have an end date. Records are never deleted — payroll, statutory and audit history outlive the employment.",
        "Approval authority attaches to a role, not to a person. When someone leaves, the authority must transfer without the record being edited."
      ],
      "commonMistakes": [
        {
          "mistake": "Deleting the record when someone leaves",
          "why": "Payroll history, approvals they gave and documents they created all lose their attribution. Deactivation is the only correct operation, and statutory retention usually requires it anyway."
        },
        {
          "mistake": "Attaching approval limits to the person rather than the role",
          "why": "Every departure becomes a permissions project, and in the gap either nothing can be approved or someone shares credentials. Both outcomes are worse than the design that avoided them."
        },
        {
          "mistake": "Conflating employee and user one-to-one",
          "why": "Shop-floor staff may need a payroll record and no login; an external auditor may need a login and no payroll record. Forcing them into one object breaks both."
        }
      ],
      "edgeCases": [
        "Contractors and consultants who need system access but no payroll record.",
        "Rehires, where a second employment period must not overwrite the first.",
        "Employees moving between group companies, where payroll transfers but service continuity may not.",
        "Someone who leaves while documents they raised are still mid-approval."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Employee",
            "note": "`status` drives payroll inclusion. Linked to User optionally — the link is deliberately not mandatory."
          },
          {
            "doctype": "User",
            "note": "The login. Separate object; permissions live here, not on Employee."
          },
          {
            "doctype": "Employee Internal Work History",
            "note": "Role and department changes over time, which is what makes historical approvals explicable."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    },
    {
      "conceptId": "bank-statement",
      "title": "Bank Statement",
      "domain": "Finance",
      "url": "https://mith.tech/concepts/bank-statement",
      "definition": "A bank statement is the bank's record of every movement into and out of an account over a period, against which a business reconciles its own books.",
      "aliases": [
        "Statement",
        "Bank feed",
        "Account statement",
        "Passbook"
      ],
      "relationships": [
        {
          "predicate": "reconciles",
          "target": "payment"
        },
        {
          "predicate": "verifies",
          "target": "general-ledger"
        },
        {
          "predicate": "belongsTo",
          "target": "company"
        }
      ],
      "lifecycle": [
        {
          "state": "Imported",
          "meaning": "Lines loaded, nothing matched."
        },
        {
          "state": "Partially reconciled",
          "meaning": "Some lines matched; exceptions outstanding."
        },
        {
          "state": "Reconciled",
          "meaning": "Every line matched or explained. The period can close."
        }
      ],
      "invariants": [
        "The statement is the external record. Where it and the ledger disagree, the ledger is the one to investigate first.",
        "Every statement line is either matched to a book entry, or it is an exception requiring explanation. There is no third category.",
        "Reconciliation is periodic and complete. A partial reconciliation that leaves unmatched lines is a deferred problem, not a finished task."
      ],
      "commonMistakes": [
        {
          "mistake": "Forcing a match to clear the reconciliation",
          "why": "The reconciliation completes and the discrepancy survives, now disguised. This is how genuine errors and occasionally fraud persist for months — the control ran and reported success."
        },
        {
          "mistake": "Reconciling only the balance, not the lines",
          "why": "Two offsetting errors produce a correct total. Balance-only reconciliation is a checksum, and a weak one."
        },
        {
          "mistake": "Treating unmatched deposits as income",
          "why": "An unidentified receipt is a liability until someone establishes whose it is. Booking it as revenue overstates the period and makes the eventual correction harder to explain."
        }
      ],
      "edgeCases": [
        "Timing differences at period end — issued but uncleared, which are legitimate and must not be forced.",
        "Bank charges and interest appearing only on the statement, needing a book entry rather than a match.",
        "Bounced payments, which appear twice on the statement and must reopen the invoice rather than net to zero.",
        "Multi-currency accounts, where the statement is in one currency and the books in another."
      ],
      "systemMappings": {
        "erpnext": [
          {
            "doctype": "Bank Transaction",
            "note": "One row per statement line. `status` moves to Reconciled only on a real match."
          },
          {
            "doctype": "Bank Reconciliation Tool",
            "note": "Matches transactions to Payment Entries. Its unmatched list is the actual output — that list is the work."
          },
          {
            "doctype": "Payment Entry",
            "note": "The book side. A payment with no statement line is either timing or fiction."
          }
        ]
      },
      "provenance": {
        "publisher": "Mith Tech",
        "lastReviewed": "2026-08-14",
        "basis": "Written from production implementation work, not vendor documentation."
      }
    }
  ]
}