Pine Labs POS Reconciliation Software for India — Terminal, MIS, MDR, GST, TDS Matching
Pine Labs reconciliation is a terminal problem, not an order-ID problem. A retail chain with 800 outlets and 1,400 terminals receives one settlement against thousands of individual TID-level transactions, deducted for MDR, 18% GST on MDR, EMI subvention, and (on commission flows) Section 393(1)(f) TDS at 5% under payment code 1007. The settlement hits a single merchant ID; the POS sales sit in 800 different outlet MIS extracts; the GSTINs may span 10 states. TransactIG reconciles at TID level, rolls up to outlet and merchant, and produces a journal-ready close per state GSTIN.
What Pine Labs Handles Natively, and Where the Reconciliation Gap Appears
What Pine Labs handles natively
Pine Labs operates the terminal fleet — card-present swipes and dips, contactless taps, on-device UPI and QR, EMI conversions, dynamic currency conversion for international cards, and gift-card and brand-EMI products. The Plutus platform consolidates the fleet, and merchant-portal MIS plus SFTP-delivered settlement files itemise transactions per TID with MDR, 18% GST on MDR, and EMI subvention broken out.
For a single-outlet small merchant, Pine Labs' own reporting is sufficient. The bank credit, the MIS file, and the till tally up by inspection.
Where the reconciliation gap appears
For chains — quick-service restaurants, retail, large-format apparel, electronics — the reconciliation problem is three-dimensional: TID-level transactions must match the per-outlet POS billing system (Inventory, sales returns, voids, refunds), outlet-level totals must roll up correctly, and merchant-level settlement must hit the bank account net of MDR, GST, EMI subvention, and TDS.
Multi-state GSTIN registrations add a fourth dimension — TIDs in Maharashtra-state outlets must post to the Maharashtra GSTIN's input GST; TIDs in Karnataka to Karnataka's. Without an automated matching layer at TID-to-GSTIN level, ITC routing fails at scale.
TransactIG Capabilities on Pine Labs
Six matching surfaces designed for the multi-terminal multi-outlet pattern — TID at the leaf, merchant ID at the root, state GSTIN as the tax-routing key.
Terminal-level MIS ingestion
Pine Labs MIS file ingested via SFTP. Terminal master maps TID to outlet to merchant ID to state GSTIN. Per-store POS billing extract joined on TID + time + amount.
MDR + 18% GST per GSTIN
MDR per card type separated from 18% GST on MDR. GST routed to the correct state GSTIN's input GL based on the TID's outlet location. Aged against Pine Labs' monthly tax invoice in GSTR-2B.
EMI subvention separation
No-cost EMI subvention deduction carried separately from MDR — sales-promotion or financing-cost classification per accounting policy. Scheme-rate validated against Pine Labs EMI table.
Section 393(1)(f) TDS — code 1007
5% TDS on commission flows under Section 393(1)(f) of the Income Tax Act 2025 (payment code 1007, replacing legacy 194H). Reconciled to Form 26AS at code level.
Outlet-level rollup and drift
TID-level matches roll up to outlet-level totals. Outlet drift surfaced where one store's MIS sales and POS billing disagree — a tell for till skim, refund leakage, or terminal misconfiguration.
Variance taxonomy
TID_TXN_MISSING_IN_POS, POS_TXN_MISSING_IN_MIS, AMOUNT_DIFF, REFUND_UNAPPLIED, EMI_SUBVENTION_DEDUCTION, OUTLET_GSTIN_MISMATCH — structured codes with maker-checker.
Pine Labs Integration — Settlement File Architecture
Each row is a discrete feed configured during implementation. Pine Labs delivers via documented MIS file delivery on SFTP; TransactIG owns the terminal-master hierarchy, POS join, and variance taxonomy.
| Source | Ingest method | Cadence | Field mapping | Variance codes |
|---|---|---|---|---|
| Pine Labs settlement MIS | SFTP delivery from Pine Labs to merchant | Daily, T+1 default | Settlement batch → merchant-ID payout | PAYOUT_MISSING_IN_BANK, AMOUNT_MISMATCH |
| Terminal-level transaction breakdown | MIS line items per TID | Per settlement | TID + time + amount → POS billing transaction | TID_TXN_MISSING_IN_POS, AMOUNT_DIFF, REFUND_UNAPPLIED |
| Terminal master (TID hierarchy) | Customer-supplied master with TID → outlet → merchant ID → GSTIN | On change (new store, terminal replacement) | TID → outlet store code + state GSTIN | TID_NOT_IN_MASTER, OUTLET_GSTIN_MISMATCH |
| POS billing extract | Per-outlet POS system daily export to SFTP | Daily per outlet | POS transaction → TID + time + amount on Pine Labs side | POS_TXN_MISSING_IN_MIS, AMOUNT_DIFF |
| MDR + 18% GST | Fee + GST columns in MIS; monthly tax invoice from Pine Labs | Per transaction, monthly tax invoice | Fee GL + GST input GL per GSTIN | FEE_RATE_MISMATCH, GST_ON_FEE_UNCLAIMED, ITC_INELIGIBLE_2B |
| EMI subvention | Subvention column in MIS for EMI transactions | Per EMI transaction | Subvention GL (sales-promotion or financing-cost) | EMI_SUBVENTION_DEDUCTION, SCHEME_RATE_MISMATCH |
| Section 393(1)(f) TDS — 1007 | TDS column in MIS; quarterly 26AS download | Per transaction, quarterly 26AS | WT line → payment code 1007 | TDS_NOT_IN_26AS, RATE_MISMATCH |
| Bank credit (net settlement) | MT940 / CAMT.053 / bank portal | Daily | Bank narration Pine Labs batch → settlement ID | NARRATION_UNPARSED, CREDIT_TIMING, NET_AMOUNT_DIFF |
Common Pine Labs Reconciliation Gaps
TID transaction missing in store POS
Card swiped on the terminal but the store's POS billing system did not capture the sale — billing system down, manual override at counter, swipe before invoice. Cash leakage tell.
POS sale with no terminal capture
POS billing records a card sale but the terminal MIS has no matching swipe — mode-of-payment misclassification, cash collected and entered as card.
EMI subvention buried in MDR line
No-cost EMI deduction lumped with MDR by default — separating the two by scheme code is required for correct sales-promotion accounting and ITC eligibility.
Multi-state GSTIN mis-routing
TID in a Maharashtra outlet posts GST against the Karnataka GSTIN — input tax credit lands in the wrong state's electronic credit ledger.
Refund and void at terminal
Card refund on the terminal and same-day void at the POS produce two reversal entries with different timestamps — needs explicit deduplication.
Terminal replaced mid-period
Hardware swap brings in a new TID — the master needs same-day update so settlements against the new TID don't drop into the unassigned-TID exception queue.
How TransactIG Reconciles Pine Labs
Ingest MIS + POS
Pine Labs MIS lands on SFTP. Per-outlet POS billing extracts land alongside. Terminal master, bank statement, GSTR-2B, and Form 26AS feeds round out the inputs.
Decompose deduction layers
Per-TID waterfall — MDR, 18% GST routed to state GSTIN, EMI subvention separated, TDS where applicable. Outlet rollup and merchant rollup computed.
Classify variances + evidence
Unmatched items route to the exception queue with TID + outlet + variance code, ageing, and audit-ready evidence. Maker-checker before GL posting.
Frequently Asked Questions
How is Pine Labs reconciliation different from a typical online payment gateway? +
Pine Labs is a POS (point-of-sale) acquirer, not an online API gateway. The reconciliation source of truth is the physical terminal — each TID (terminal ID) accepts card swipes, EMI conversions, UPI on-device, and increasingly QR-based payments at a specific store or counter. The settlement file is structured around terminals and outlets, not around payment IDs in an order-management system. For multi-outlet chains — quick-service restaurants, retail chains, large-format stores — a single settlement may cover hundreds of terminals across dozens of outlets. TransactIG reconciles at terminal level, rolls up to outlet, and matches against the store's POS billing MIS plus the bank credit.
What does the Pine Labs settlement file contain? +
Pine Labs publishes a daily settlement MIS to the merchant, structured around terminal-level transactions — each card swipe, EMI conversion, UPI-on-device payment, refund, void, and any reversal, with the MDR, 18% GST on MDR, and (for EMI) the merchant-funded subvention component itemised. Larger chain merchants typically receive this via SFTP delivery on a defined schedule, supplemented by a merchant-portal export. Pine Labs' Plutus platform consolidates this across the terminal fleet. TransactIG ingests the MIS file, joins it to the per-store POS billing extract (TID + transaction time + amount), and matches both against the net bank credit per outlet or per merchant ID.
How does TransactIG handle multi-terminal multi-outlet chains? +
A chain with, say, 800 outlets and 1,400 terminals (some outlets have multiple counters) sees a single Pine Labs merchant-ID settlement that aggregates across the entire fleet. The reconciliation requires three-level hierarchy: TID at the bottom, outlet (store code) in the middle, merchant ID at the top — with the bank credit hitting the merchant level and the POS billing data living at the outlet level. TransactIG configures this hierarchy at onboarding from a customer-supplied terminal master, then runs daily matches that surface drift at any of the three levels: TID-level mismatches (one terminal under-settling), outlet-level (one store's MIS off), or merchant-level (total credit short).
How is the MDR and 18% GST on Pine Labs fees classified? +
MDR varies by card type — debit, credit, premium credit, international, commercial — and by EMI scheme. Pine Labs deducts MDR per transaction plus 18% GST on MDR. TransactIG separates the MDR from the GST in the journal, classifies the GST-on-fee component as ITC-eligible input tax (subject to the merchant's GST registration and Rule 36(4)), and ages the provisional ITC until Pine Labs' monthly tax invoice appears in GSTR-2B. For chain customers with multiple GSTINs across states, TransactIG maps each TID to its correct state GSTIN — a single Pine Labs merchant ID can span multiple GST registrations.
How is EMI subvention handled? +
No-cost EMI is funded by the merchant — Pine Labs converts a card swipe to an EMI plan, the issuing bank charges the customer no interest, and Pine Labs deducts an upfront subvention from the settlement to compensate the bank. The deduction comes off the merchant's gross sale alongside the regular MDR. TransactIG separates the MDR component from the subvention component in the journal entry — the MDR is a financing cost, the subvention is a marketing or sales-promotion expense depending on the merchant's accounting policy. Different GST treatment may apply on the subvention; TransactIG carries it on a separate variance code (EMI_SUBVENTION_DEDUCTION) for visibility.
How long does Pine Labs reconciliation implementation take? +
2 to 4 weeks. Week one configures the Pine Labs SFTP delivery, maps the terminal master (TID to outlet to merchant ID to GSTIN), and aligns the MDR rate card and EMI scheme table. Week two configures the per-outlet POS billing extract from the customer's point-of-sale system (whether that is a major POS vendor or a custom system), the bank statement ingest at merchant level, and the journal-entry template. Weeks three and four cover variance taxonomy tuning for the customer's specific patterns and the maker-checker workflow. Chain customers with active terminal-master change-control (new stores opening, terminals replaced) get a self-service master refresh.
Terminal-to-bank reconciliation for chains running Pine Labs
TID-level matching with outlet rollup, MDR and 18% GST routed to the correct state GSTIN, EMI subvention separated, Section 393(1)(f) TDS reconciled. 2 to 4 weeks, ISO 27001:2022, AWS Mumbai.