ENCOR (ISS45) Transaction Log Analytics: Sales, Shrink, and Fraud Detection

Every grocery and retail chain running ENCOR is generating a continuous, byte-level record of every action at every lane, every minute the registers are open. That record — the transaction log — captures every line item, every tender, every void, every override, every loyalty scan. Reading the format cleanly opens up sales analytics, shrink detection, and the cashier-side fraud signatures that live at the individual-event level.

Shrink is real, fraud is real, the patterns are in the data, and the tools to surface them start with parsing the log correctly. Standard summary reports — total sales by lane, total voids by cashier, total refunds by store — give the aggregate picture. The parsed log adds the individual events that drive each of those totals: which item, which timestamp, which sequence, which customer, which authorization.

A summary report shows that Cashier 47 voided three hundred and twelve dollars yesterday across thirteen voids. The parsed log shows that all thirteen voids hit the same lane in the last ninety minutes of the shift, that each one followed within seconds of a coupon scan, and that the customer at four of those thirteen transactions was the same loyalty member. The first view is the totals; the second is the signature. The signature view is where loss-prevention investigation starts.

What's actually in the log

Every line item: PLU scanned, description recorded, quantity, weight where applicable, scanned price, taxes applied, every discount and promotion that triggered against the line. Every transaction-level event: subtotal, totals, every tender accepted, change calculated, exact timestamps, lane number, cashier ID, and customer identifier whenever a loyalty card was scanned. Every exception: line voids, full transaction voids, refunds with their original-transaction references where available, no-sales, price overrides, manager authorizations, supervisor overrides. Every loyalty event: member card scans, segment associations, points earned, rewards redeemed, coupons scanned and applied or rejected. Every operational event: drawer opens whether tied to a tender or not, training-mode entries, suspended transactions, recalled transactions, end-of-shift sequences.

This is the granularity the parsed log adds on top of the standard nightly reports. A polling-summary view tells management what happened in aggregate. The parsed log tells exactly what happened, in sequence, at every register, by every cashier, on every shift, for as long as the log retention window allows.

Summary reports and signature-level analysis answer different questions. Summary reports answer "is anything off in aggregate?" The parsed log answers "where, by whom, when, and how?" That second question is the one that drives loss prevention investigations, supports merchandising decisions about specific promotions, gives finance the ability to reconcile cash variances down to the second the drawer opened, and gives IT the audit trail for any dispute that arrives later — from a customer, a payment processor, or a regulator.

Use cases by stakeholder

Loss prevention and asset protection. Sweethearting detection. Void abuse patterns. Refund fraud signatures. Even-money void clustering that brings transactions to round dollar amounts before tender. Post-void refund pairing within the same transaction or short window. Manager override anomalies clustered by cashier and supervisor. No-sale frequency by cashier shift over shift. Discount stacking abuse where promotions, coupons, and overrides accumulate beyond what policy allows. The data carries every one of these patterns, and the parsed log surfaces them — the shift from totals to signatures gives LP teams the precision to act on specific events instead of investigating shifts in aggregate.

Finance and operations. True cashier productivity measured as scans per hour adjusted for void rate, not the gross figure that mixes legitimate fast cashiers with cashiers running scan-and-void schemes. Shift-by-shift labor efficiency tied to actual transaction throughput. Basket composition trends by daypart, by store, by promotional period. Actual-versus-promotional pricing reconciliation that catches misapplied discounts before they accumulate. Cash variance explanation that ties every penny of difference to a specific event in the log. Tender mix evolution as the customer base shifts toward digital payment methods.

Merchandising and marketing. Promotion lift attribution at the line-item level, not the aggregate level — knowing exactly which items, in which baskets, in which stores, the promotion actually moved. Basket affinity analysis built on the actual co-purchase data rather than category-level estimates. True price elasticity by SKU using the natural experiment of every promotional period. Item-level promotion ROI that includes the cannibalization across substitute products, not just the lift on the promoted item. Loyalty-segment behavioral profiling that surfaces what each segment actually buys versus what marketing assumes they buy.

IT and store systems. Lane-level uptime and exception monitoring built on the log's operational events. End-of-day reconciliation troubleshooting when the totals don't match. Audit trails for compliance with PCI, with state and local tax authorities, with payment-processor disputes. Root-cause data for any customer dispute that arrives weeks after the transaction. The log is the system of record for what happened at the register, and every downstream question eventually traces back to it.

Same data asset. Four stakeholder groups. The chains that extract it cleanly get all of these capabilities from a single source they already own.

Cashier-side patterns

Sweethearting. A cashier scans a low-priced item while ringing up a higher-priced item for a known customer — typically a friend, a family member, or a regular. The customer pays for the cheap item; the expensive item leaves the store. The signature in the log: PLU-versus-described-item mismatches when both are recorded, unusual price-per-line distributions for specific cashier-customer pairings, repetition of the same low-PLU-high-frequency combination across multiple transactions tied to the same loyalty member.

Void abuse. A cashier voids a line, or an entire transaction, after the customer has already paid and left, then pockets the cash difference at the end of the shift. The signature: void timing relative to tender completion, voids clustered by cashier and shift, voids on cash-tender transactions disproportionately compared to card-tender transactions where the difference cannot be pocketed without leaving an electronic trail.

Refund fraud. Refunds processed against transactions that never occurred, or duplicating legitimate refunds, or processing refunds when the customer is not present. The signature: refunds without a matched original transaction in the surrounding time window, refunds clustered by cashier independent of customer-driven return patterns, refund amounts that follow round-number distributions rather than the natural distribution of original purchase totals.

Even-money voids and post-void refund pairs. Voids that bring a transaction to an exact round dollar amount, often paired with a subsequent refund processed shortly after. The signature: void-to-round-amount detection, void/refund pairing within a transaction or short window, repetition of the pattern by the same cashier across days.

No-sale-before-tender patterns. Opening the drawer before completing a transaction, often correlated with cash skimming. The signature: no-sale events temporally close to large cash tenders, no-sale frequency by cashier independent of legitimate operational reasons.

Authorization and override patterns

Discount stacking abuse. Stacking promotions, coupons, and manager overrides in combinations the chain's policy doesn't allow. The signature: line-level discount accumulation that exceeds the permitted threshold, manager-override frequency on specific cashier-customer combinations, override authorizations clustered around shift changes when supervision is reduced.

Manager override anomalies. Supervisor authorizations clustered in unexpected ways. The signature: the same supervisor authorizing repeated overrides for the same cashier, overrides occurring at consistent times relative to shift changes, override values that follow patterns inconsistent with legitimate exception handling.

Each of these patterns is detectable in the parsed log. Knowing shrink is happening is one level of awareness; knowing exactly where, by whom, when, and how is the level signature-level analysis on the parsed transaction log opens up.

The schema-first approach

I have approached the parsing problem differently. Rather than write parsers, I build machine-readable schemas of the transaction log format itself — structured documents that describe every record type, every field, every conditional structure, every edge case I have ever encountered in production data, including the records and field combinations that vendor documentation does not cover.

From those schemas, the parsing infrastructure produces clean, structured outputs: transactions, line items, events, exceptions — every signal in the log surfaced as data ready for analytics platforms, data warehouses, BI tools, or purpose-built dashboards. The same schema feeds every downstream consumer; there is no per-tool parser drift.

When a new edge case appears, I update the schema. Every downstream pipeline picks up the change automatically. There is one source of truth, not a dozen forks of an aging parser scattered across engagements and gradually diverging from each other and from the data they are supposed to read.

The same schema-first methodology applies to other retail POS log formats — but each format has its own structure, its own evolution, and its own catalog of edge cases. The methodology is portable; the schemas themselves are specific to each platform.

From raw log to analytics-ready data

The schema-first approach is the methodology. The service is the pipeline that brings it to your environment. Most chains generate transaction-log files daily but have no practical path from those files into the analytics tools their teams already use. The work that pays back is connecting the two.

I build the delivery pipeline that does the connecting. Wherever your raw log files live today — at the store level, in a central archive, or both — the pipeline reads them, parses each record through the schema, and delivers structured outputs (transactions, line items, events, exceptions) into your existing analytics tools, data warehouse, BI environment, or purpose-built dashboards. Each delivery is verified before it lands so the failure modes show up at processing time rather than in a downstream report.

Both engagement models work. Build-once: I deliver the pipeline plus the schemas, and your engineering team runs it on your cadence — daily, hourly, or near-real-time depending on the use case. Ongoing service: I run the parsing infrastructure and deliver structured data into your environment on the cadence the consuming teams need. Same underlying schemas and pipeline either way; the difference is who runs it.

What's coming

The schema-first parsing infrastructure described above feeds into a forthcoming analytics platform purpose-built for grocery shrink and fraud detection — built on the same schemas, designed to surface the patterns described in this article without requiring each chain to build its own analytics stack from raw log data. More on that as it nears release. For now, the parsing infrastructure itself is what unlocks the log; the analytics layer on top is the natural next step.

How JA Technology Solutions helps

The work falls into a small number of categories, each tied to an outcome.

Transaction log extraction — clean, structured outputs from the ENCOR transaction log, feeding your existing analytics tools, your data warehouse, or your BI environment. Engaged as a build-once project (your team runs the pipeline going forward, with the schemas I maintain) or as an ongoing service (I run the parsing infrastructure and deliver structured data on your cadence).

Custom dashboards and reports — purpose-built views for loss prevention, finance, merchandising, and operations, built on the parsed log and tuned to the questions your team is actually asking. Not generic templates, not vendor-canned reports.

Shrink and fraud pattern engagements — surfacing the patterns hiding in your transaction history, identifying the specific loss vectors active in your environment, and building the ongoing monitoring that catches them when they recur.

Integration with existing analytics infrastructure — feeding parsed log data into the tools your team already knows, so the new capability lands inside the workflows they are already using rather than requiring everyone to learn a new platform.

Ongoing support contracts — keeping the parsing infrastructure current as ENCOR releases evolve and new record types appear. The schemas are maintained; the pipelines stay reliable.

I have done this work at a large regional grocery chain running ENCOR across the fleet, where the LP and merchandising teams now have access to the patterns the standard reports were never going to surface for them.