RFID Software: How It Works & What to Integrate
Tags and readers only produce raw reads; software is what turns them into stock counts, alerts, movements and invoices. This chapter follows the data from the reader to your ERP and gives a definitive checklist of what every RFID software should include and integrate.
- A reader reports raw reads (EPC, antenna, RSSI, timestamp); software filters them into events and applies business rules.
- The item or asset master that maps each EPC to a real-world object is the heart of every RFID system.
- Good RFID software covers device management, encoding and printing, counts, movements, search, alerts, reports, roles and audit trail.
- Integration with ERP, WMS, POS or accounting (SAP, Oracle, Microsoft Dynamics, Tally or custom) is usually where the business value is realised.
- Ask vendors about offline handheld sync, APIs, data ownership, security, scalability and support before you buy.
Why software is the real RFID system
When people picture RFID they picture tags and readers. But a reader on its own only does one thing: it reports that it has seen certain tag numbers on certain antennas. It does not know that EPC 3034... is a gold chain in tray 4, that tray 4 should be in the vault after 8 pm, or that the chain was sold an hour ago. All of that meaning comes from software.
In practice, most of the effort, cost of ownership and business value in an RFID project sits in software: how reads are cleaned, how they are turned into events, how those events update stock and assets, and how the results reach the people and systems who need them. A strong tag and reader choice with weak software produces a lot of data and very little benefit. This chapter explains the software chain end to end and then gives a checklist you can use to evaluate any RFID application. For the internal workings of the filtering layer itself, see RFID Middleware & Software; here we focus on the full picture and on what to integrate.
How RFID software works, end to end
Every RFID system, from a small library to a national toll network, follows roughly the same flow of data.
1. The reader produces raw reads
A UHF reader (in India, operating in the 865-867 MHz band at up to 4 W EIRP, which typically means about 1 W from the reader into a moderate-gain antenna) inventories tags many times per second. Each read normally carries the tag's EPC, the antenna port that saw it, a signal strength value (RSSI), a timestamp and sometimes the TID, phase or a user-memory value. A single tag sitting in front of an antenna can generate dozens of reads per second, and tags just outside the intended zone may appear intermittently.
2. The edge or middleware layer filters and creates events
Raw reads are noisy and repetitive, so the next layer removes duplicates, ignores tags that do not belong to your EPC scheme, applies RSSI thresholds and time windows, and converts the stream into meaningful events such as "tag first seen at Dock 2", "tag left zone" or "carton moved inward". This can run on the reader itself, on an edge PC or gateway, or in the cloud. The middleware chapter covers these techniques in depth.
3. Business logic gives the event a meaning
The application then looks up the EPC in the item or asset master and applies rules: a garment moving from back-room to sales floor is a replenishment; a laptop passing the exit gate without an approved gate pass is an alert; a tray read at closing time with one piece missing is an exception. This is where the software must understand your process, not just RFID.
4. The database records the state and history
Each accepted event updates the current state (where an item is, its status, who has it) and is stored in a history log. The history lets you answer questions later: when was this asset last seen, how many wash cycles has this towel done, which counter held this ring yesterday.
A note on handhelds
Handheld readers follow the same chain, but the first three layers often run inside the mobile app itself. The app reads tags, removes duplicates, compares them with the expected list it downloaded before the count, and shows found, missing and extra items on screen. Only the result - or the batch of reads - is sent to the server, either live over Wi-Fi or 4G or later when the device is back in coverage. That is why offline capability and clean synchronisation rules matter so much for handheld work: if two users count the same zone, or an item was sold while the count was in progress, the server must resolve the conflict predictably and record who did what.
5. Users and other systems consume the results
Finally, the results appear on screens and reports, trigger notifications, and flow to the ERP, WMS, POS or accounting system as transactions such as goods receipts, stock transfers or count adjustments. Instructions also flow the other way: the ERP sends purchase orders or item masters, and the RFID application tells readers and printers what to do.
What every RFID software should integrate: the checklist
Not every project needs every module on day one, but a mature RFID platform should cover the following. Use this table as a requirement list when talking to vendors or planning your own development.
| Module | What it does | Why it matters |
|---|---|---|
| Device and reader management | Configures readers (power, antennas, sessions, filters), monitors health and connectivity, manages firmware updates. | A reader that silently goes offline produces "missing" stock. Central monitoring catches problems before users do. |
| Tag commissioning and encoding | Generates unique EPCs, writes them to tags, verifies the write, optionally locks memory. See RFID encoders explained. | Duplicate or badly written EPCs break every downstream process. |
| Label and tag printing | Sends print-and-encode jobs to RFID printers with barcode and human-readable text, and handles void tags. See the RFID printers guide. | Most tagging happens through printers; poor control leads to wasted labels and mismatched data. |
| Item / asset master and EPC mapping | Links each EPC to an item, SKU or asset record with attributes (description, weight, serial, cost, owner). | This mapping is the heart of the system. Without it a read is just a number. |
| Barcode fallback | Lets users scan the barcode or QR printed on the tag when RFID cannot be read. | Damaged tags and difficult items always exist; work must not stop. |
| Locations, zones and hierarchy | Models sites, buildings, floors, rooms, racks, counters or trays, and links readers and antennas to zones. | Reports and movements only make sense when locations mirror the real site. |
| Read filtering and event rules | Deduplicates reads, applies RSSI and time windows, defines rules such as "in", "out", "dwell" and "missing". | Turns noisy reads into reliable business events and prevents false alerts. |
| Inventory and cycle count | Handheld app for full and partial counts, compares found vs expected, shows missing and extra items; works offline and syncs later. | The most common RFID benefit. Offline sync matters in vaults, basements and large yards with poor Wi-Fi. |
| Movement and in/out with direction | Uses fixed readers at doors and gates to record movement and direction. See fixed reader installation. | Automatic receiving, dispatch and exit control without manual scanning. |
| Search and locate | Guides a user with a handheld towards a specific tag using signal strength (a "geiger counter" mode). | Finding one misplaced item among thousands is a daily need. |
| Alerts and notifications | Sends SMS, WhatsApp, email or in-app alerts for unauthorised exits, missing items, low stock or offline readers. | Real-time exceptions are where RFID prevents loss rather than just recording it. |
| Dashboards and reports | Stock by location, count accuracy, movement history, ageing, exceptions; export to Excel or PDF. | Managers judge the system by its reports. |
| User roles and audit trail | Role-based permissions; logs who did what and when, including edits to master data. | Essential for high-value goods, audits and accountability. |
| ERP / WMS / POS / accounting integration | Exchanges masters and transactions with SAP, Oracle, Microsoft Dynamics, Tally or custom systems via REST APIs, webhooks, file exchange or database connectors; device-level protocols such as LLRP and MQTT on the reader side. | Avoids double entry and keeps the financial system of record accurate. |
| Data security and privacy | Encryption in transit and at rest, strong authentication, data retention rules, consent and purpose limits where personal data is linked. | Where tags link to people (staff, patients, students), India's DPDP Act 2023 places duties on how personal data is processed. |
| Multi-site, cloud or on-premise | Supports many branches or warehouses under one tenant; deployable in the cloud, on your servers or hybrid. | Growth and IT policy should not force a platform change. |
| Backup and recovery | Scheduled backups, tested restores, edge buffering when the server is unreachable. | Losing the EPC mapping means re-tagging or re-mapping everything. |
| Scalability and performance | Handles growth in tags, readers, users and event volume without slowing down. | A pilot with 5,000 tags behaves very differently from production with 5 lakh. |
| Mobile apps | Android apps for handheld readers and phones with Bluetooth sleds: counting, receiving, issue/return, search. | Most daily RFID work is done on handhelds, so usability here decides adoption. |
| Analytics | Trends such as shrinkage, dwell time, asset utilisation, turnover and replacement forecasting. | Moves the system from record-keeping to decision support. |
How integration with ERP and other systems is done
Integration is usually the most underestimated part of an RFID project. There are three common directions of data flow:
- Masters into RFID: item, SKU, asset, location, customer and user lists flow from the ERP into the RFID application so tags can be commissioned against real records.
- Documents into RFID: purchase orders, sales orders, transfer orders and pick lists tell the RFID system what is expected, so it can verify what is actually received or dispatched.
- Transactions back to ERP: confirmed receipts, dispatches, transfers and stock-count adjustments flow back so the financial books match physical reality.
Common methods
- REST APIs and webhooks: the modern default; near real-time, easy to secure and monitor.
- Vendor connectors: standard interfaces or middleware for large ERPs such as SAP, Oracle or Microsoft Dynamics. These often need the ERP partner's involvement.
- File exchange: scheduled CSV, Excel or XML files. Simple and robust, but not real-time. Common with smaller accounting packages, including many Tally setups.
- Database or message queue integration: direct staging tables, or brokers such as MQTT for event streams.
- Reader-side protocols: LLRP (the standard reader protocol) and vendor SDKs connect readers to middleware; MQTT and HTTP are increasingly offered directly by readers.
Questions to ask an RFID software vendor
- Which of our processes are covered by your standard product, and which need customisation?
- Which readers, handhelds and printers do you support, and are they from several manufacturers or one?
- Does the handheld app work offline, and how are conflicts resolved during sync?
- How do you integrate with our ERP or accounting system? Can you show a running example with the same system?
- Do you provide documented APIs and webhooks? Can we export all our data at any time in a standard format?
- Who owns the data and the EPC mapping? What happens to our data if we stop the subscription?
- Cloud, on-premise or both? Where is the data hosted, and how is it encrypted and backed up?
- How are user roles, audit trails and personal data handled, including our duties under the DPDP Act?
- What volumes (tags, events per second, users, sites) are you running today at your largest site?
- What are the licence model, annual support terms, response times and upgrade policy?
- Who configures readers on site and who fixes problems at 9 pm on a Saturday?
Costs vary enormously with scope. As an indicative guide only, a ready-made application for a single site with standard reports may be a modest one-time licence or a monthly subscription, while a multi-site platform with ERP integration and custom workflows can run into several lakh rupees of implementation effort plus annual support. Always get quotes against your written requirements.
Build vs buy
The middleware chapter discusses build-vs-buy for the filtering layer. For the complete application, the decision usually looks like this:
| Option | Best when | Risks |
|---|---|---|
| Buy a ready product | Your process is common (retail stock, asset tracking, library, laundry, jewellery) and speed matters. | May need process changes; check data export and vendor stability. |
| Buy and customise | The core fits but integrations, reports or a few workflows are specific to you. | Scope creep; insist on a written specification and acceptance tests. |
| Build in-house | RFID is part of your own product or the process is truly unique, and you have long-term developers. | Underestimating reader quirks, offline sync, filtering and maintenance effort. |
Most organisations do best with the middle path: a proven RFID platform for devices, encoding, counting and events, with custom integration and reporting built around it.
Practical tips for a smooth software rollout
- Clean the master data first. Duplicate SKUs, missing serials and wrong locations will be faithfully reproduced by RFID.
- Define the EPC scheme early so encoding, printing and integration all use the same format. See EPC encoding and memory.
- Pilot the full chain, including the ERP posting, not just the read rate.
- Write acceptance tests in business terms: "a count of 2,000 items matches expected within the agreed tolerance", "a gate exit alert arrives within the agreed time".
- Plan for exceptions: unreadable tags, re-tagging, returns, items without tags and manual overrides, all with an audit trail.
- Train by role. Store staff need the handheld app; supervisors need exceptions and reports; IT needs device management and integration monitoring.
Getting help with RFID software
Indian RFID, the RFID division of Mindware, provides RFID software and integration services, connecting readers, handhelds and printers with ERP, WMS, POS and accounting systems for Indian businesses. If you are planning a project, our RFID consulting team can help you write requirements and evaluate options. To build these skills formally, the RFID courses in India page lists our practical training programmes.
Help India adopt this fast-growing technology - teach, consult or build projects with Indian RFID.
Frequently asked questions
Do I need separate RFID software if I already have an ERP?
Usually yes. ERPs are not built to handle thousands of raw reads per second, filter duplicates or manage readers, so an RFID layer sits between the readers and the ERP and sends it clean transactions.
Can RFID software work with Tally?
Yes, many Indian RFID deployments exchange item masters, stock movements and vouchers with Tally through its import/export or integration interfaces, but the exact method depends on your Tally version and the software vendor.
Is cloud RFID software safe?
It can be, if data is encrypted in transit and at rest, access is role-based, backups are tested and the provider explains where data is stored. Some organisations still prefer on-premise for policy reasons.
What happens if the network goes down during a stock count?
A well-designed handheld app stores counts locally and synchronises when the connection returns, and fixed readers or edge devices buffer events so nothing is lost.
Should we build our own RFID software?
Build only if RFID is core to your product or your process is truly unique and you have long-term developers; most organisations buy a proven platform and customise integrations and reports.
Join the 1-month Certified RFID Specialist Program - live online. New batch 12 January 2027.