At the counter
Import your product list, customers and suppliers from Excel
Bring what you already have. AgroPOS reads an .xlsx file for products, for customers and for suppliers, so a shop with its catalogue in Excel — or a list an accountant keeps — does not type it in twice. Download the template, paste your rows in, and open it.
Nothing is saved until you have seen what it will do. AgroPOS reads the file first and shows you the list: how many rows are new, which ones you already have, and which cannot be used and why, naming the row so you can find it in Excel. For every record that already exists you decide, row by row, whether to leave it alone or update it — there is no hidden setting that silently overwrites your shop.
Updating changes the details, never the money. An import will not move a customer’s udhaar balance, a supplier’s payable, or a product’s stock: those belong to your bills and purchases. Opening stock on a new product becomes real, sellable stock with its own batch and expiry, and a customer’s old balance goes in once as a single opening figure.
Column order does not matter and spare columns are ignored, so a stock report exported out of AgroPOS can be edited in Excel and fed straight back in.
Fast enough for a queue
A sale is three actions: find the product, set the quantity, confirm. The receipt prints on its own if you want it to. Everything runs on your own PC against a local database, so no screen waits on a connection — on a mandi morning with five farmers at the counter, that is the whole difference.
Finding the product is the part most software gets slow. AgroPOS searches on brand name, company, barcode or the technical name of the chemical at the same time, so typing chlorpyrifos lists every brand of it you stock. The farmer names the chemical; the shelf carries brand names; you should not have to translate between them.
Getting started is quick too. Installing takes a couple of minutes on any Windows 10 or 11 PC and most shops bill on the same day. The part that takes real time is entering your product list and opening balances, and that is included — we do it with you, in Urdu, rather than handing you an empty screen.
Billing till (POS)
Search a product by name, Urdu name or barcode, set the quantity and take payment as cash, credit or partial. Discounts can be entered in rupees or as a percentage, and a percentage is converted before it is saved — so every receipt and report shows a settled cash figure.
Batch-wise inventory
Stock is held per batch, not per product. Each batch keeps its own batch number, expiry date, pack size, purchase rate and supplier. Sales take from the earliest-expiring batch first, so older goods move before they become a write-off.
Stock that shows but will not sell
Type an opening quantity when you create a product and the figure is recorded — but the till sells from batches, and an opening quantity creates none. So the product reads “25 in stock” and every attempt to bill it answers “out of stock”.
Pending Stock lists exactly those products and walks you through the ordinary purchase that makes them sellable — your supplier, your rate, your choice of cash or udhaar. Nothing is guessed on your behalf, because only you know who you bought from.
Expiry and low-stock alerts
The dashboard shows what is expiring within a window you choose, and what has fallen below its reorder level. Expired batches are blocked at the till — a cashier cannot sell them by mistake.
Hold a bill and come back to it
A customer says "add two bags of urea, I'll be back" and walks off to the godown. Hold the bill, serve the next customer, and bring it back with one click — as many held bills at a time as the counter needs, each named so you can find it ("Kashif", "red pickup", "gate par").
A held bill is not a sale. No invoice number is issued and no stock is reserved, so a cart forgotten overnight costs nothing and leaves no gap in your invoice numbering. When you resume it, every line is re-priced against live stock: anything that sold out in the meantime is removed and anything short is reduced to what is actually on the shelf, and the till tells you which lines changed rather than letting you find out in front of the customer.
Walk-in cash sales
A customer who is not on your list can be billed without being added first — but on cash only. Credit always needs a named customer, because udhaar owed by nobody is udhaar you will not collect. The receipt prints without a customer block.
Sale history and old-date billing
Every sale is searchable by invoice number, customer or date. Filter by a single day, not just a range, with Today and Yesterday shortcuts. A sale can also be entered with an earlier date, so a shop starting mid-season can put its existing sales in on the days they actually happened.
Receipts and invoices
80 mm thermal receipts and full A4 invoices, both printed through the normal Windows printer system. Save as PDF or send straight to WhatsApp. On a credit sale the receipt prints the customer's previous balance, this bill's udhaar and the new total.
Set your thermal printer once and every sale prints itself the moment it is confirmed — no dialog to click through at a busy counter.
Money owed, both directions
Customer ledger
Every customer carries a running balance and an optional credit limit. The till warns before a sale would push someone past their limit. Customers are stored with father's name and village, because that is how a rural counter actually identifies people.
Recovery management
A single list of everyone who owes you, with their full history. Recording a payment settles it against the oldest unpaid invoices first, so the ledger stays honest rather than becoming a pile of part-paid bills.
Settling a khata short
A customer owes Rs 51,000 and says he will give 50,000 to close the account. Zeroing the balance by hand would lose the 1,000 entirely: the sale already counted it as earnings, so your books would report money you never received.
Take the payment and tick Settle the account. The khata closes at zero and the forgiven amount is recorded as a write-off expense with that customer’s name on it, so it comes out of profit and you can see at season’s end exactly how much was forgiven and to whom. Admin only — a cashier taking payments all day cannot forgive a balance.
Purchases and suppliers
Purchases are entered against batches, and the Supplier Ledger shows total business done with each supplier, what you have paid and what is still payable — with a printable statement. Purchases paid on delivery appear there too, so the account is complete.
Wholesale — selling to other shops at a trade rate
Plenty of agri-input dealers sell to farmers and to smaller shops in the villages around them. Those are two different rate cards, and running both out of one price list means either the shop gets the retail rate or the farmer gets the trade rate. AgroPOS keeps them apart.
Mark a customer as a Shop and give the business its own name — that name is what prints on the bill, not the person who came to collect. Set one wholesale rate on each product, and the shop pays it whether they hand over cash or take udhaar, because a trade price is about who is buying, not how they settle.
At the till, Wholesale is a fourth tab beside Cash, Credit and Partial. It lists only your shop customers; the other three list only farmers. Neither can be billed off the wrong rate card by picking from the wrong list. Enter what the shop actually paid and the rest goes to their khata, exactly like a partial sale.
There is more on how the two rate cards stay apart, and what happens when a party buys and sells, on the wholesale and distribution page. A product with no wholesale rate set falls back to your normal price rather than billing nothing. And the whole thing is off until you switch it on — a shop that only sells to farmers never sees a customer type, a second rate box or a fourth tab.
One khata for a party you both buy from and sell to
Some parties go both ways. You sell surplus stock back to a distributor; you buy a pallet off the shop down the road when you run short. Kept as a customer account and a supplier account, that is two balances for one person and a reconciliation you do in your head every time they walk in.
Link them and AgroPOS keeps one netted khata. Sell them Rs. 50,000 and buy Rs. 200,000 from them, and the account reads what it should: Rs. 150,000 you owe — one figure, counted once. It shows in your payables and not at all in recovery, so the dashboard does not double it.
Their statement shows both sides: what you sold, what you bought from them, and the net. Sale returns, purchase returns, payments and recovery all land on the same account, each in the right direction. Also off by default.
Sale and purchase returns
Returns adjust stock and the ledger together, so a refund never leaves the two disagreeing.
For the Agriculture Department
Inspector Mode
Seven registers print for any date range: stock, batch-wise stock, expiry, sales, purchase, company-wise stock and daily sales. Each carries your shop letterhead and dealer licence number. Purchase prices and stock valuation are deliberately left off — the inspector needs the record, not your margins.
Read what each register must show →
Item-wise inspection
Track a single product's full history — what came in, from which supplier and batch, and where it went.
Product compliance fields
Each product carries its registration number, technical (active ingredient) name and formulation code — EC, WP, SC, SG, OD and the rest of the CropLife list. An Urdu product name can be stored alongside the English one.
The owner's view
Dashboard
The figures an owner opens the software to see, on one screen: today's cash and credit sales with the invoice count, stock value on hand, pending recovery, supplier payable, and a twelve-month sales chart for the year. Beside them sit the two lists that cost money when nobody looks — batches expiring within the window you choose, and products that have fallen below their reorder level.
Profit and loss, by any period
One tap for Today, This Month, Last Month or This Year, or pick any range. Sales, less returns, less what the goods actually cost, less shop expenses by category, and the net profit with its margin as a percentage of sales.
The cost used is the rate each batch was bought at, so a figure from last season does not change when a new delivery arrives dearer. Profit by product ranks lines by what they earn rather than by turnover — usually a different order than dealers expect. And if any sold item has no purchase rate recorded, the statement says so and warns that the real profit is lower, rather than quietly counting that whole sale as profit.
Back office
Profit and loss statement
A working profit and loss for any period you choose — a week, a month, a whole season. Sales, less returns, less what the goods actually cost you, less your shop expenses broken down by category, and the net profit at the bottom with its margin as a percentage of sales.
The cost used is the rate each batch was bought at, not today's rate for that product, so last season's profit stays what it was when a new delivery arrives at a different price. If any sold item has no purchase rate recorded, the statement says so and warns that the real profit is lower — rather than quietly counting that whole sale as profit. A loss is shown as a loss.
Profit by product
Which lines actually earn, ranked by profit rather than turnover. The product that sells most often is frequently not the one that earns most, because the fast lines are the ones every shop stocks and the rate is squeezed.
Wallets and bank accounts
Add as many accounts as the shop uses, and Easypaisa, JazzCash, SadaPay, NayaPay and UPaisa wallets alongside them. A bank account is set up with its bank name, account title, account number and branch; a wallet with its provider and the mobile number the money is sent to. Record money in and money out, with every entry showing the balance the account stood at after it, so the list reads like a statement. Entries can be dated back, and the balances above and below correct themselves. Any account prints a PDF statement for a period or for its whole history. The screen totals what the banks hold and what the wallets hold separately, because a dealer checks Easypaisa against Easypaisa's own statement, not against a figure with the bank folded in.
Posting payments to an account automatically
By default nothing in AgroPOS writes to an account except the dealer. That is what makes these figures worth checking: a record the software kept and a record the bank kept, made separately, that agree.
A dealer who takes twenty Easypaisa payments a day can switch that off in Settings. With it on, a sale, a recovery, a purchase, a supplier payment or an expense taken by wallet, bank transfer or cheque writes itself into the account it went through, and the cash carried to the bank at day close can name the account it was paid into. Each payment method gets a default account, so the usual case is chosen already and can still be changed at the counter.
Cash is never posted to an account, whatever the setting. Cash is in the drawer and is counted at day close; writing it to an account as well would count the same notes twice and report a shortage every evening. And a bill that is later cancelled keeps its account entry rather than quietly reversing it, because the money may genuinely have reached the bank and a cancelled bill does not un-receive it — AgroPOS points the entry out and the dealer decides.
Bookings — pay now, lift later
A farmer pays for 100 bags of khaad in September at September’s rate, then collects them across the season — 20 bags now, 30 next month. Before this, that could only be recorded as one sale, which takes all the stock out of the godown on day one, or as a bare advance, which leaves no record of what was booked or at what price.
A booking records both. The rate is locked on the day the money changes hands, because fixing the price is the whole reason the farmer paid early. The advance is held against those exact goods rather than sitting as loose credit on the khata, so a later udhaar sale cannot quietly spend it and leave the last twenty bags unfunded.
Goods go out through the till, in Booking mode, and each collection prints a gate pass carrying quantities only — no rupees, because the farmer already paid and a slip showing money would read like a third bill. Stock leaves and profit lands on the day the goods actually move, not on the day the money arrived, so the godown count matches the software and the day close is not thrown out by a sale whose cash was taken weeks earlier.
The screen also answers the question no dealer can keep on paper: which bookings are still waiting, how much is still owed in goods, and how long the oldest has sat. Booking more than the advance covers, or more than the godown holds, is allowed — AgroPOS says so and leaves the decision where it belongs.
Party Settlement — your customer pays your supplier
A customer owes the dealer, the dealer owes a company, and rather than money going round twice the dealer says: pay them directly. The customer sends it, forwards the transaction ID, and two khatas have changed with nothing in the till to show for it.
AgroPOS records that as one event. The customer’s khata comes down, what the dealer owes the company comes down by the same amount, and the transaction ID is kept against both — because six months later the only proof any of it happened is that reference. The bills on each side are settled oldest first, exactly as a cash payment would settle them.
Nothing reaches the day book, and that is deliberate. No notes entered the drawer, so counting this at day close would report a surplus that is not there. Nor is any wallet or bank account of the shop’s touched: the money moved between the customer’s account and the company’s, and neither belongs to the dealer.
Before it is saved the screen shows both khatas as they stand and as they will stand. If the amount is more than the customer owed, it says so — the remainder becomes credit the dealer owes him. If it is more than the dealer owed the company, it says that too, and the remainder sits as an advance against the next consignment. A settlement recorded in error is reversed rather than deleted, and both khatas move back together.
Switched off by default, because it only makes sense where a dealer and his customers deal with the same companies. Turning it off later hides the screen and changes no khata: every settlement already moved the balances when it was recorded.
Cash lent to a customer
Sometimes a customer walks in, takes no goods at all, and asks for money against his name — to be settled later, like anything else on his khata. Every dealer does it and no software had a place to put it.
So it got recorded as one of two wrong things. A made-up bill, which moves stock that never left the godown and books profit that was never earned. Or an expense, which is worse: an expense is money gone, and this money is coming back. A season of lending recorded that way leaves the profit statement understated by every rupee of it.
AgroPOS records it for what it is. The customer’s khata goes up exactly as an udhaar bill would leave it, so recovery collects against it with no difference at all — to the dealer there is none, and there is none in the software either. The drawer goes down, because the notes left it, so the day close still reconciles. Lend it from Easypaisa or a bank account instead and it comes off that account rather than the drawer.
The profit statement never hears about it, and that is the point. No expense is written, because nothing was spent. The khata carries it until it comes back, and the statement shows it as a cash loan rather than a sale, so a dealer reading it months later can tell debt from goods apart from debt from money handed over.
A customer’s credit limit applies to it just as it applies to a bill. Lending against a name already at its ceiling is exactly what the limit exists to stop.
Cheque Register — a cheque is a promise, not money
A farmer hands over a cheque at the counter. Most software marks the bill paid there and then, and the khata says he owes nothing — on the strength of a piece of paper the bank has not yet honoured. When one bounces, the dealer is left unwinding a payment that never happened.
AgroPOS records the cheque and leaves the khata exactly where it was. The goods go out, the balance stands, and the cheque is filed in its own register with its number, bank and the date written on it. Post-dated cheques are ordinary in this trade, so the register holds them until the day they can be presented.
When the bank honours it, the khata moves — on that day, with the same ledger entry, the same oldest-bill settlement and the same account posting any other payment gets. The dealer says how it cleared: cashed over the counter, so the notes are in the drawer and the day close expects them; or deposited, so it shows on that account’s statement and the drawer is left alone.
If it bounces, there is nothing to reverse, because nothing had moved. It is marked, the reason is kept, and it is there the next time that customer offers one.
A cheque can also be passed straight to a supplier against the dealer’s own bill. Nothing moves then either — and when it clears, both khatas settle at once: the customer has paid the dealer, and the dealer has paid the supplier, without a rupee passing through the shop or any account of his. An endorsed cheque cannot then be cashed or banked by the dealer, because he is no longer holding it.
Switched off by default. It cannot be switched off while any cheque is still outstanding, because money is owed on every one of them and hiding the register would leave no way to find out whose.
Expenses
Day-to-day spending recorded by category and date, and included in the profit and loss statement. A shop coming onto AgroPOS mid-season can enter everything it spent beforehand as one dated opening total, rather than typing months of entries one at a time.
Reports and Excel export
Sales, purchases, stock, expenses and recovery, each over a date range you choose, exportable to Excel when you want to work on the numbers yourself.
Your details, your format
Your shop name, address, phone, NTN and dealer licence appear on printed documents. You can upload your own logo, and the invoice footer is yours to write — the paperwork should read as the shop's, not ours.
See who changed what
Staff can be trusted and still make mistakes. A rate that looks wrong three months later, a credit limit nobody remembers raising, a tax percent that changed at some point — these used to leave no trace at all, because an edit simply overwrote what was there.
Change History records edits to the things that move money: product rates, credit limits, tax percent, invoice numbering, and user roles and accounts. Each entry shows what the value was, what it became, who changed it and when. Passwords are never recorded — only that one was changed. Admin only.
Keeping the money figures off the counter
A dashboard sits open all day on a screen customers lean across to sign for their goods. On it are the figures that say what the shop is worth — the value of the godown, what is owed to the shop, and what the shop owes. None of that is a customer’s business, and a dealer should not have to close the screen every time somebody walks in.
An eye at the top of the dashboard covers every rupee figure at once, and uncovers them again. Covered, they read as stars — all of them the same width, because a longer row of stars would itself say which figure is the big one. Counts carry on showing: how many products are short and how many are near expiry are work, not wealth.
The same figures are restricted by role. By default only the owner sees them; a cashier or a store manager gets stars, and no eye to open them with, while everything else on their dashboard works exactly as before. Like every other permission it is a row the shop controls, so a trusted manager can be given the figures back.
The eye is remembered per computer. In a multi-counter shop the till by the door faces the customers and the office machine does not, so covering the figures at one does not cover them at the other.
Users and permissions
Separate accounts with Admin, Cashier and Store Manager roles, so each person signs in as themselves instead of sharing one login. Discounts and price edits need the right authority.
Close the day by counting the drawer
How much cash should be there
Every evening the same question: is the money in the drawer the money that should be in it? Until you can answer that, a shortage is something you notice weeks later as a gap you cannot explain.
The Day Book takes the float you started with, adds the cash that came in from sales and recovery, subtracts cash expenses, cash purchases, supplier payments and anything you took to the bank — and tells you what should be in the drawer right now.
At closing time you count the notes and enter the total. The software says whether it matches, and by how much it is short or over. Short usually means a payment taken without a bill, or cash that left without an expense entry. Over usually means a sale billed as udhaar that was actually paid. Either way you find out the same day, while somebody still remembers.
The count is a count, not a copy
The expected figure stays hidden until you have typed what you counted. Seeing the answer first turns counting into copying, and then a real shortage is never noticed. It is shown after you enter your total, and only if you ask for it.
Udhaar is not in the drawer
Credit sales sit on the khata, not in the till, so they are left out of the cash figure — the day’s full takings are shown separately. And nothing is frozen when a day closes: enter a back-dated bill next week and that day’s figures correct themselves, instead of quietly disagreeing with your ledger.
Cash, Easypaisa, JazzCash, bank or cheque
When money changes hands the till asks how it arrived. This is what makes the day close worth trusting: only cash goes into the drawer, so a customer who pays Rs 40,000 by Easypaisa is income but not drawer cash. Counted as cash, every evening would show Rs 40,000 missing.
The question is only asked when something is actually being paid — a full udhaar sale is not asked, because nothing has been paid yet. Recovery payments record the method too.
Who can close the day
A Store Manager or Admin. A cashier hands over the notes; the person who signs the day off is the one answerable for a shortfall.
It keeps working
Fully offline
Billing, stock, ledgers and reports all run on your own PC. Internet is used three times only: to activate the licence once, to upload cloud backups, and to download updates. When the line drops mid-season, the shop keeps trading.
Automatic backup — every 10 minutes, local and cloud
Nobody has to remember to back up. Every 10 minutes AgroPOS checks whether anything has changed, and when it has, it writes a backup file on your own PC first and then uploads an encrypted copy to the cloud — both, never one without the other. Closing the software backs up again whatever the timer says, so the day's work is off the machine before you lock the shop.
If the internet is down when a backup is due, the local copy is still written and the cloud copy goes up when the line returns. Old local copies are pruned automatically so the drive does not fill. A stolen PC or a dead hard disk costs you the machine, not the season.
Cloud backup is included with every licence — free for the first year, then Rs 5,000 a year if you want to keep uploading. Local backup is unconditional: it never stops and costs nothing, and if you ever choose not to renew the cloud half, your existing cloud backups stay downloadable.
Updates install themselves
AgroPOS checks for a new version on its own and installs it in the background. You keep billing; it asks you to restart when it is ready. There is nothing to download, no setup file to hunt for and nobody to call.
Updates are free for the life of the licence. New features and fixes are not sold to you again as a new version, and there is no maintenance contract. If the shop is offline the update simply waits until the next time you have a connection — it never blocks the counter.
Cloud backup
Backups are tied to your licence key rather than the machine. Install on a new PC, activate with the same key, and your earlier backups are listed there ready to restore. Local ZIP backups in your Documents folder restore directly.
Recovery dates, and a credit score that means something
A dealer’s real question in the morning is not “who owes me” — it is “who said they would pay today”. When a customer names a date, record it. Recovery Dates then lists everyone due today alongside every date that has already slipped, oldest first, because the slipped ones are the ones that get forgotten.
Green when the date is still good, red once it has passed. The colour is readable across a counter without reading a word.
Every customer carries a credit score out of 10. It starts at 10, and a date that passes with nothing paid costs one point — nothing else does. Not the size of the balance, not how long they have owed. A farmer carrying 300,000 who pays on every date he names is a good customer; one carrying 20,000 who has broken four dates is not.
Part payment on the day keeps the promise. Somebody who owed 50,000, said the 12th and brought 20,000 on the 12th turned up and paid — that costs nothing.
Below 5, the till warns before a credit sale, in English and Urdu, with what they promised and how late it is. It does not block the sale: you often know something the software does not. The owner can reset any score back to 10, and the promise history is kept either way.
Parchoon: selling khaad by the kilo
A farmer wanting ten kilos out of a fifty-kilo bag is an ordinary sale in a zarai markaz, and one most tills cannot bill: they count bags, so ten kilos is “0.2”.
With parchoon switched on, picking a bag of khaad asks Full Bag or by the Kg. The loose sale is charged at that product’s own per-kilo parchoon rate — higher than the bag divided down, which is the whole point — and the receipt, the khata and the sale history all say 10 Kg.
When the open kilos run short the next bag is opened automatically, and the till says so first: “1 more bag will be opened for this sale.” Stock always reads 19 bags + 30 Kg — never a fraction of a bag.
Nothing to set up beyond one switch and a per-kilo rate: the software works out which products can be split from the pack size you already entered on the purchase. Spray and seed never show the option.
On your phone, when you are not at the shop
AgroPOS Mobile is a free Android app that comes with your licence. It shows your customers and their khata, your recovery list, suppliers, shops and stock — so a customer who stops you in the field gets a straight answer instead of “I will check at the shop”.
You can generate any customer’s account statement as a PDF and send it over WhatsApp while you are standing there: what they purchased, what they paid, the balance, and a signature line.
It is read-only. Nothing on the phone can change your books, so a lost handset is an inconvenience and not an accident. Connecting is one QR scan from Settings → Mobile App on the PC — no account, no password. Up to three phones per licence.
See it on your own counter
The 14-day trial is the complete software with nothing switched off. Enter a real day of purchases and sales, then print an inspection register and decide.