Marketplace TCS and TDS records: reconcile separate deductions

When an Indian marketplace settles order proceeds to a seller, the payout remittance typically reflects two distinct statutory withholdings alongside commercial marketplace fees: Tax Collected at Source (TCS) under the Goods and Services Tax framework and Tax Deducted at Source (TDS) under the Income-tax framework for e-commerce operators. Although both appear as negative deductions reducing the net cash deposited into the merchant's bank account, they belong to entirely different legal regimes, follow different calculation bases, map to different tax identifiers (GSTIN versus PAN), and are recovered through separate government portals and filing cadences. In day-to-day retail operations across marketplace sellers; omnichannel, tax manager with settlement finance teams repeatedly confront a structural governance challenge: how to maintain distinct deduction types, reporting sources and effective legal mappings; require current-law review before explaining treatment. When teams rely on fragmented manual spreadsheets or unverified summary totals across inventory deduction fields; map regime and statement sources; reconcile identifiers and periods; investigate corrections; review current legal references, operational exceptions accumulate silently across period boundaries and corrupt downstream management reporting.

A costly accounting failure occurs when ERP integration connectors or settlement bookkeepers collapse both withholdings into a single 'Marketplace Tax Withheld' account—or worse, bundle them into marketplace commission expense. Bundling them expenses recoverable tax assets directly against P&L margin and leaves the tax team unable to reconcile monthly state-wise GST TCS credits or quarterly/annual PAN-level TDS certificates (Form 16A / Form 26AS). The core operational mandate for tax manager with settlement finance is to answer the central governance question—How should seller finance reconcile tax deductions without mixing different tax regimes and reporting periods?—by implementing a repeatable control framework where every deduction traces to its source and reviewed legal mapping, with unresolved labels visible. (Income Tax Department, Government of India — E-Filing and Tax Deducted/Collected at Source (TDS/TCS) FAQs, Goods and Services Tax Network (GSTN) — GSTR-2B Auto-Drafted ITC Statement User Guide and FAQs). By linking this control to Marketplace Settlement Reconciliation and Retail Invoice and Credit-Note Records, tax manager with settlement finance teams prevent downstream financial, operational, and audit breaks before records or funds move.

Why must marketplace Tax Collected at Source (TCS) and income-tax Tax Deducted at Source (TDS) deductions be maintained in completely separate sub-ledgers and statutory reconciliation trails?

GST TCS and income-tax TDS are statutory tax assets withheld on the seller's behalf, not commercial fees charged by the marketplace. Each requires its own asset clearing sub-ledger, its own base-value validation formula, and its own portal reconciliation workflow.

Key takeaway: Both reduce net payout cash, neither is a marketplace fee expense. GST TCS and income-tax TDS are statutory tax assets withheld on the seller's behalf, not commercial fees charged by the marketplace. Each requires its own asset clearing sub-ledger, its own base-value validation formula, and its own portal reconciliation workflow.

To eliminate ambiguity between operational execution and accounting or compliance verification, tax manager with settlement finance teams must replace ad-hoc spreadsheet overrides with a deterministic control model. Specifically, the workflow must answer the primary operational question—How should seller finance reconcile tax deductions without mixing different tax regimes and reporting periods?—by enforcing explicit conservation and state-transition rules across every transaction record.

To prevent cross-regime contamination in settlement accounting, the ERP posting engine must split every settlement payout into independent statutory conservation equations:

• Net_Bank_Remittance = Gross_Customer_Proceeds - Commercial_Marketplace_Fees - Fee_GST - Withheld_GST_TCS - Withheld_IncomeTax_TDS
• Expected_GST_TCS(state_gstin) = Net_Taxable_Supplies_Via_Marketplace(state_gstin) * Statutory_TCS_Rate
• Expected_IncomeTax_TDS(pan) = Gross_Sales_Or_Credit_Base(pan) * Statutory_TDS_Rate

Structural failure modes in unmanaged retail workflows

When organisations attempt to manage marketplace TCS TDS reconciliation and ecommerce withholding reconciliation; seller tax deduction records; TCS TDS statement matching without an explicit state machine, four recurring operational failure modes degrade auditability:

• Netting TCS and TDS into a Single Clearing Account: Combining GST TCS and income-tax TDS makes it impossible to reconcile state-level monthly GST returns against PAN-level quarterly income-tax statements. In multi-channel retail environments (marketplace sellers; omnichannel), this failure mode compounds whenever upstream data feeds (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries) arrive asynchronously without strict schema validation or document-level status tracking.

• Booking Statutory Withholdings as Marketplace Fee Expense: Treating TCS or TDS as a commercial cost understates net profit and forfeits direct tax credits already paid on the company's behalf. In multi-channel retail environments (marketplace sellers; omnichannel), this failure mode compounds whenever upstream data feeds (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries) arrive asynchronously without strict schema validation or document-level status tracking.

• Ignoring Negative Return Adjustments Across Month Boundaries: High return volumes in a post-sale month can flip a state's net taxable marketplace sales negative, creating a timing divergence between settlement deductions and GST portal TCS filings. In multi-channel retail environments (marketplace sellers; omnichannel), this failure mode compounds whenever upstream data feeds (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries) arrive asynchronously without strict schema validation or document-level status tracking.

• Hardcoding Tax Rates Without Base Verification: Marketplace operators may adjust TDS/TCS logic when thresholds are crossed or when credit notes are processed; always reconcile both the tax amount and the underlying base reported by the operator. In multi-channel retail environments (marketplace sellers; omnichannel), this failure mode compounds whenever upstream data feeds (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries) arrive asynchronously without strict schema validation or document-level status tracking.

When designing the data pipeline around settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries, teams must ensure that every line item is evaluated individually rather than netted inside summary control totals. Furthermore, when an edge-case exception arises—specifically, when a platform uses a legacy section label; a tax specialist confirms current mapping before the article or workflow is approved.—the workflow must quarantine the record in a dedicated review state rather than permitting an undocumented bypass.

By separating each discrepancy category in the matrix above, tax manager with settlement finance teams ensure that operational root causes are resolved at the source document level before period-end sign-off. This directly supports the practical tooling strategy recommended for marketplace sellers; omnichannel merchants: configure reviewed mappings in existing tax/accounting systems; avoid hard-coded rates or section assumptions in integration code. Moreover, by structuring the workflow around the core stages of inventory deduction fields; map regime and statement sources; reconcile identifiers and periods; investigate corrections; review current legal references, leadership gains real-time visibility into open exposure before financial statements or regulatory filings are locked.

  <path d="M219 85 L248 85" stroke="#475569" stroke-width="1.8" marker-end="url(#arrow-r080)"/>

  <rect x="248" y="40" width="195" height="90" rx="8" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.5"/>
  <text x="262" y="64" font-weight="700" fill="#854d0e">2. GST TCS Track</text>
  <text x="262" y="84">State GSTIN sub-ledger</text>
  <text x="262" y="102">Monthly portal TCS match</text>
  <text x="262" y="118" font-size="11" fill="#475569">Owner: Tax & Settlement Lead</text>

  <path d="M443 85 L472 85" stroke="#475569" stroke-width="1.8" marker-end="url(#arrow-r080)"/>

  <rect x="472" y="40" width="195" height="90" rx="8" fill="#ffedd5" stroke="#ea580c" stroke-width="1.5"/>
  <text x="486" y="64" font-weight="700" fill="#9a3412">3. Income-Tax TDS Track</text>
  <text x="486" y="84">Corporate PAN sub-ledger</text>
  <text x="486" y="102">Quarterly 26AS/AIS match</text>
  <text x="486" y="118" font-size="11" fill="#475569">Owner: Tax & Settlement Lead</text>

  <path d="M667 85 L696 85" stroke="#475569" stroke-width="1.8" marker-end="url(#arrow-r080)"/>

  <rect x="696" y="40" width="200" height="90" rx="8" fill="#dcfce7" stroke="#16a34a" stroke-width="1.5"/>
  <text x="710" y="64" font-weight="700" fill="#166534">4. Specialist Exception</text>
  <text x="710" y="84">Legacy/unknown labels</text>
  <text x="710" y="102">Tax sign-off before map</text>
  <text x="710" y="118" font-size="11" fill="#475569">Owner: Tax & Settlement Lead</text>

  <rect x="24" y="166" width="872" height="164" rx="8" fill="#ffffff" stroke="#cbd5e1" stroke-width="1.2"/>
  <text x="44" y="194" font-weight="700" font-size="13" fill="#0f172a">Governance & Exception Control Gates (R080)</text>
  <text x="44" y="220" fill="#334155">• Gate A: Input Contract — Capture settlement tax lines, GSTIN/PAN identifiers, portal statements, and legal mappings.</text>
  <text x="44" y="246" fill="#334155">• Gate B: Exception Guard — Quarantine unfamiliar or legacy withholding codes for tax specialist mapping before posting.</text>
  <text x="44" y="272" fill="#334155">• Gate C: Acceptance Rule — Trace every deduction to its statutory sub-ledger (GST TCS vs Income-Tax TDS) and portal return.</text>
  <text x="44" y="302" font-weight="600" fill="#0369a1">Outcome: Zero commingled withholding accounts, separating ₹5,000 GST TCS (GSTIN) from ₹1,000 income-tax TDS (PAN) on ₹10,00,000 net sales.</text>
</g>
<defs>
  <marker id="arrow-r080" viewBox="0 0 10 10" refX="8" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
    <path d="M 0 0 L 10 5 L 0 10 z" fill="#475569"/>
  </marker>
</defs>

Worked operational and financial example: marketplace tcs and tds records: reconcile separate deductions

Illustrative example (hypothetical scenario): Consider how this workflow operates in practice when applied to a concrete retail scenario: One settlement has two differently labelled tax deductions. Keep each as its own ledger and evidence trail rather than combining them into a generic marketplace fee.

Step 1: Establish the baseline operational and financial parameters

Worked Example (Split Ledger Accounting for One Settlement): Consider Settlement SET-2026-109 for a merchant selling through a national marketplace under its Karnataka GSTIN and corporate PAN:

• Net Taxable Supplies (after returns): ₹1,000,000.00 plus 18% output GST (₹180,000.00) = ₹1,180,000.00 gross customer collections.
• Commercial Marketplace Fees & GST: ₹150,000.00 commission/fulfilment fees + ₹27,000.00 (18% GST) = ₹177,000.00.
• Deduction 1 — GST TCS (0.5% IGST/CGST+SGST illustrative effective rate on net taxable value): ₹1,000,000.00 * 0.005 = ₹5,000.00.
• Deduction 2 — Income-Tax E-Commerce TDS (0.1% illustrative rate on gross base ₹1,000,000.00): ₹1,000,000.00 * 0.001 = ₹1,000.00.

The marketplace remits Net_Bank_Remittance = ₹1,180,000.00 - ₹177,000.00 - ₹5,000.00 - ₹1,000.00 = ₹997,000.00. Instead of recording ₹6,000.00 (₹5,000.00 + ₹1,000.00) into a single deduction line, the ERP posts:

1. ₹5,000.00 to 1410-KA-GST-TCS-Receivable (tagged with Karnataka GSTIN, matched monthly against the GST portal TCS return).
2. ₹1,000.00 to 1420-PAN-IT-TDS-Receivable (tagged with corporate PAN and operator TAN, matched quarterly against Form 26AS/AIS). If a settlement file contains a third line with an unfamiliar or legacy section code (for example, SEC_LEGACY_WITHHOLDING_₹750), the ingestion rule routes that ₹750.00 to 1499-Unclassified-Tax-Withholding-Review and alerts the tax manager rather than guessing the sub-ledger.

To ensure that every variable in this calculation is traceable back to an authoritative source table in the ERP, WMS, OMS, or compliance repository, the data engineering and finance teams enforce the following schema and reconciliation contract across all participating systems:

• Withheld_GST_TCS (GST TCS Sub-Ledger (by GSTIN)): Tax Collected at Source under GST law on net taxable supplies made through the electronic commerce operator. Operational control rule: Reconciled monthly per state GSTIN against GST portal TCS statement.
• Withheld_IncomeTax_TDS (Income-Tax TDS Sub-Ledger (by PAN)): Tax Deducted at Source under income-tax provisions for e-commerce participants. Operational control rule: Reconciled quarterly/annually at corporate PAN level against Form 26AS / AIS.
• Net_Taxable_Supplies_Via_Marketplace (GST Base Calculator): Taxable sales minus taxable returns settled through the marketplace in the period. Operational control rule: Excludes GST component; negative net returns floor or carry per portal rules.
• Gross_Sales_Or_Credit_Base (Income-Tax Base Calculator): Statutory base for e-commerce income-tax TDS calculation as defined by the applicable section. Operational control rule: Tracked across settlements by merchant PAN and operator TAN.

By binding each calculation term directly to its source document identifier and timestamp across settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries, the reconciliation engine guarantees that any downstream audit reviewer can reconstruct the exact figure without manual spreadsheet archaeology.

Step 2: Reconcile states, exceptions, and financial or compliance impact

The reference implementation below demonstrates how the reconciliation and classification rules execute deterministically in code without permitting silent netting or unverified status transitions:

Python Reference Implementation: Statutory Deduction Classifier and Router

from dataclasses import dataclass
from typing import Dict

APPROVED_TAX_CODE_MAP = {
    'GST_TCS_CGST': ('GST_TCS', '1410-GST-TCS-RECEIVABLE'),
    'GST_TCS_SGST': ('GST_TCS', '1410-GST-TCS-RECEIVABLE'),
    'GST_TCS_IGST': ('GST_TCS', '1410-GST-TCS-RECEIVABLE'),
    'IT_TDS_ECOM': ('INCOME_TAX_TDS', '1420-IT-TDS-RECEIVABLE'),
}

@dataclass
class SettlementTaxLine:
    settlement_id: str
    raw_code: str
    amount_inr: float
    merchant_gstin: str
    merchant_pan: str

def route_statutory_deduction(line: SettlementTaxLine) -> Dict[str, object]:
    if line.raw_code not in APPROVED_TAX_CODE_MAP:
        return {
            'regime': 'UNCLASSIFIED_HOLD',
            'ledger_account': '1499-TAX-CODE-REVIEW-SUSPENSE',
            'identifier_key': line.settlement_id,
            'amount_inr': line.amount_inr,
            'requires_specialist_signoff': True
        }
    regime, account = APPROVED_TAX_CODE_MAP[line.raw_code]
    identifier = line.merchant_gstin if regime == 'GST_TCS' else line.merchant_pan
    return {
        'regime': regime,
        'ledger_account': account,
        'identifier_key': identifier,
        'amount_inr': line.amount_inr,
        'requires_specialist_signoff': False
    }

When deploying this logic into staging or production pipelines, engineering and finance teams verify each variable against the authoritative data contract summarized in the control matrix below:

Verified scenario calculation summary

• Net_Bank_Remittance = Gross_Customer_Proceeds - Commercial_Marketplace_Fees - Fee_GST - Withheld_GST_TCS - Withheld_IncomeTax_TDS
• Expected_GST_TCS(state_gstin) = Net_Taxable_Supplies_Via_Marketplace(state_gstin) * Statutory_TCS_Rate
• Expected_IncomeTax_TDS(pan) = Gross_Sales_Or_Credit_Base(pan) * Statutory_TDS_Rate

This worked scenario demonstrates why every deduction traces to its source and reviewed legal mapping, with unresolved labels visible. Without preserving separate document states and explicit audit trails across inventory deduction fields; map regime and statement sources; reconcile identifiers and periods; investigate corrections; review current legal references, leadership cannot verify whether reported balances reflect clean operational execution or offsetting errors. In addition, when the exception rule triggers—a platform uses a legacy section label; a tax specialist confirms current mapping before the article or workflow is approved.—the automated quarantine prevents unverified figures from contaminating downstream ledgers.

Step-by-step implementation procedure for tax manager with settlement finance teams

Implementing this control across inventory deduction fields; map regime and statement sources; reconcile identifiers and periods; investigate corrections; review current legal references requires a structured operational sequence that coordinates tax manager with settlement finance responsibilities from initial data capture through final audit sign-off. Whether your organisation operates as a marketplace sellers; omnichannel business, the following step-by-step procedure establishes a defensible audit trail:

1. Maintain a Versioned Tax Deduction Code Dictionary: Map every marketplace settlement transaction type and statutory section label explicitly to either GST_TCS, INCOME_TAX_TDS, or COMMERCIAL_FEE. Block unmapped codes from auto-posting to P&L or active tax ledgers. Ensure that all required inputs (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries) are logged with immutable timestamps and user or system identifiers before advancing the workflow state, and verify that any record triggering the exception rule (a platform uses a legacy section label; a tax specialist confirms current mapping before the article or workflow is approved.) is routed immediately to the designated reviewer.
2. Partition Sub-Ledgers by Statutory Identifier: Configure GST TCS receivable accounts with mandatory Merchant_GSTIN and Operator_GSTIN dimensions, and configure Income-Tax TDS receivable accounts with mandatory Merchant_PAN and Operator_TAN dimensions. Ensure that all required inputs (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries) are logged with immutable timestamps and user or system identifiers before advancing the workflow state, and verify that any record triggering the exception rule (a platform uses a legacy section label; a tax specialist confirms current mapping before the article or workflow is approved.) is routed immediately to the designated reviewer.
3. Validate Deduction Bases Against Order-Level Activity: At the end of each month, recompute expected GST TCS from net taxable sales per state and expected income-tax TDS from gross sales/credits, flagging any marketplace rate or base divergence. Ensure that all required inputs (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries) are logged with immutable timestamps and user or system identifiers before advancing the workflow state, and verify that any record triggering the exception rule (a platform uses a legacy section label; a tax specialist confirms current mapping before the article or workflow is approved.) is routed immediately to the designated reviewer.
4. Reconcile Against External Government Statements: Match the GST TCS sub-ledger line-by-line against the marketplace's filing in the GST portal before transferring credit to the Electronic Cash Ledger, and match the TDS sub-ledger against quarterly Form 26AS/AIS entries. Ensure that all required inputs (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries) are logged with immutable timestamps and user or system identifiers before advancing the workflow state, and verify that any record triggering the exception rule (a platform uses a legacy section label; a tax specialist confirms current mapping before the article or workflow is approved.) is routed immediately to the designated reviewer.
5. Escalate Legacy or Ambiguous Section Labels: Whenever a marketplace updates its settlement schema or introduces a legacy/transitional section label, route the line to the tax specialist review queue for formal classification. Ensure that all required inputs (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries) are logged with immutable timestamps and user or system identifiers before advancing the workflow state, and verify that any record triggering the exception rule (a platform uses a legacy section label; a tax specialist confirms current mapping before the article or workflow is approved.) is routed immediately to the designated reviewer.

Following these steps consistently ensures that every deduction traces to its source and reviewed legal mapping, with unresolved labels visible. Every exception remains visible, aged, and assigned to an accountable owner until resolved, and joint process-owner and specialist sign-off is recorded before period close.

Data lineage, exception handling, and system configuration boundaries

Before deploying this workflow across marketplace sellers; omnichannel operations, tax manager with settlement finance teams must lock down four structural specifications that govern how records move from source capture to final sign-off:

• Authoritative input data contract: Every run of this workflow must ingest and version-stamp the required source fields: settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries. Do not allow downstream summaries or manual adjustments to bypass these primary inputs; if a required identifier, timestamp, or supporting document reference is absent from the feed, hold the record in a pre-posting staging queue rather than interpolating missing values.
• Deterministic exception quarantine rule: Operational streams routinely encounter edge cases that violate standard matching assumptions—specifically, a platform uses a legacy section label; a tax specialist confirms current mapping before the article or workflow is approved. Rather than forcing an automated override or silently netting out the discrepancy, isolate the anomalous record in a dedicated exception state with its full supporting evidence bundle attached for human review.
• Pragmatic system architecture and tooling choice: Configure reviewed mappings in existing tax/accounting systems; avoid hard-coded rates or section assumptions in integration code. Avoid over-engineering custom integration code before the underlying business rules, approval limits, and exception classifications are proven stable in a controlled operating model.
• Verifiable acceptance and audit standard: The workflow is only considered production-ready when every deduction traces to its source and reviewed legal mapping, with unresolved labels visible. Furthermore, before any external reporting or policy reliance, require joint sign-off from the designated process owner and specialist reviewer confirming that all sample calculations, state transitions, and exception queues reconcile to primary source queries.

Operational governance and audit controls for sustained compliance

To prevent this workflow from eroding after the initial implementation sprint across inventory deduction fields; map regime and statement sources; reconcile identifiers and periods; investigate corrections; review current legal references, embed four recurring governance checkpoints into your weekly retail operations cadence:

1. Version-locked rule and threshold tables: Store every tolerance band, status-transition rule, and exception-routing map in a versioned configuration table rather than ad-hoc personal spreadsheets. Any threshold change requires sign-off from tax manager with settlement finance and commercial finance, recording the effective timestamp and the cohort of transactions or accounts affected.
2. Automated daily orphan and stale-state sweep: Run a scheduled morning query that flags records stuck in an intermediate state (Pending Verification, Awaiting Evidence, Held for Review, or Disputed) beyond their agreed service-level cutoff. Route aged exceptions directly to the named role owner before period-close or regulatory cutoffs are breached.
3. Separation of operational execution from financial or compliance sign-off authority: Staff who execute operational entries, catalogue updates, or customer service actions should never have unilateral system permission to clear reconciliation variances, alter legal mappings, or post financial write-offs. Require independent review once cumulative adjustments exceed your materiality floor.
4. Monthly root-cause retrospective tied to source-system hygiene: Aggregate exception logs by upstream root cause—such as missing remittance references, unversioned rate-card changes, or unmapped channel fields—and require the responsible upstream team to remediate the top three recurring defects before the next monthly cycle.

Observable acceptance tests for your retail systems

Before relying on this workflow in production, execute three deterministic acceptance tests (ACT-R080-01 to ACT-R080-03) in your staging environment or controlled worksheet:

Common pitfalls to avoid and next actions for tax manager with settlement finance teams

When rolling out this workflow across marketplace sellers; omnichannel operations, audit your current processes against the four most common operational pitfalls below and execute the corresponding remediation actions:

1. Eliminate the pitfall of netting tcs and tds into a single clearing account: Combining GST TCS and income-tax TDS makes it impossible to reconcile state-level monthly GST returns against PAN-level quarterly income-tax statements. Replace this failure pattern by enforcing automated pre-posting validation, explicit state flags across (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries), and mandatory evidence attachments in your workflow tool before any record advances to production sign-off.
2. Eliminate the pitfall of booking statutory withholdings as marketplace fee expense: Treating TCS or TDS as a commercial cost understates net profit and forfeits direct tax credits already paid on the company's behalf. Replace this failure pattern by enforcing automated pre-posting validation, explicit state flags across (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries), and mandatory evidence attachments in your workflow tool before any record advances to production sign-off.
3. Eliminate the pitfall of ignoring negative return adjustments across month boundaries: High return volumes in a post-sale month can flip a state's net taxable marketplace sales negative, creating a timing divergence between settlement deductions and GST portal TCS filings. Replace this failure pattern by enforcing automated pre-posting validation, explicit state flags across (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries), and mandatory evidence attachments in your workflow tool before any record advances to production sign-off.
4. Eliminate the pitfall of hardcoding tax rates without base verification: Marketplace operators may adjust TDS/TCS logic when thresholds are crossed or when credit notes are processed; always reconcile both the tax amount and the underlying base reported by the operator. Replace this failure pattern by enforcing automated pre-posting validation, explicit state flags across (settlement tax lines; tax identifiers; official statements; effective legal mapping; amendments; ledger entries), and mandatory evidence attachments in your workflow tool before any record advances to production sign-off.