Product
Store Spends is used by the person spending, the person accountable for the store, and the team that has to explain the numbers. Each sees exactly what their role requires.
The surfaces
Access is derived from the signed-in session and enforced on the server — not hidden in the interface.
A guided phone flow: pick a category, scan the vendor's UPI QR, enter the amount, review, pay. Their own limit is shown before they start, and any bill they still owe is on the home screen.
The store's balance, the day's activity and recent payments across every employee at that location, with each transaction opening in full.
The console: funding, approvals, org configuration and reporting across every location under the merchant.
How it works
The whole sequence happens at the counter, on the employee's phone, in the time it takes to pay.
A store employee opens the app, picks a category, scans the vendor's UPI QR and enters the amount.
The platform applies the employee's limits, permitted categories and the store's available balance before anything moves.
The payment is executed against the settlement adapter and returns a reference. The transaction is written at the same moment.
The employee photographs the invoice. Bill number, date, amount and GST attach to that transaction.
The spend is booked against the store, employee, category and vendor, and the store balance updates.
Store, finance and platform views reflect the payment — no month-end collation step.
Nothing is retrofitted. The transaction record, the approval decision and the bill are created as the payment happens — which is why the reports do not need a month-end reconciliation pass to become true.
Key features
These are built and running, not roadmap items. Where a capability is licensed separately or still pending a banking-partner integration, it says so.
Staff scan a vendor QR or pay a UPI ID from the store's funded balance. No cards to issue, no cash to reconcile. Settlement runs through a sandbox adapter today, pending banking-partner integration.
Limit, permitted category and available store balance are enforced before money moves — not reviewed afterwards. Funding and configuration changes carry a separate maker–checker–executor approval chain.
Platform roles (super admin, sales operations, merchant admin) and merchant capability profiles (merchant admin, finance operator) sit above store managers and store employees. Each sees only what their level requires.
Daily and monthly limits per employee, with expense categories inherited from their designation.
Balance, spend and exceptions for each location, and for the store manager, their own store in full.
A vendor master for the payees you use often, without restricting staff to it — any valid UPI QR remains payable.
Bills are photographed on the phone at the point of purchase and attached to the transaction, with GST fields where present.
Spend by store, category, employee and vendor, current as of the last settled payment.
An append-only event record for every payment, funding decision, approval and configuration change, with the actor and timestamp on each entry.
Built for organisations running tens or hundreds of locations under one entity, with per-store funding and balances.
Ledger and transaction exports in the formats a finance team already works in, with the settlement reference on every line. Export is a licensed capability — confirm it is in scope for your engagement.
Security
We describe only the controls that are implemented today. Store Spends does not currently claim any third-party compliance certification, and we will not imply one. If your procurement process requires a security review, we will complete your questionnaire directly.
Server-side sessions with hashed credentials. Employees sign in on a mobile number with a one-time code, and each employee account is bound to a single active device.
All traffic is served over HTTPS with HSTS. Application data is held in a managed PostgreSQL instance with encrypted connections.
Permissions are enforced on the server for every request, not hidden in the interface. Scope is derived from the session, never from a parameter the caller supplies.
Payments, approvals, funding decisions and configuration changes are written to an append-only audit record with actor, action and timestamp.
A modular service layer over PostgreSQL, with maker–checker–executor separation on funding and change management, idempotent execution and per-entity locking.
Money moves over UPI rails to the vendor's own account. Store Spends records and controls the spend; it does not hold customer funds.
The fastest way to judge whether Store Spends fits is to walk one of your stores through it. We will tell you honestly if it does not.
Tell us your structure — locations, categories, approval rules — and we will show the platform against it.
A working session for finance and operations teams. Roughly 45 minutes, no slides.
Commercial terms, deployment scope, security questionnaires and procurement paperwork.