<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
  <title>Irsaal — notes from the round</title>
  <link>https://irsaalsystems.com/blog</link>
  <description>How to run a water, milk or LPG delivery business well — routes, bottles, recovery and the software behind them.</description>
  <language>en-PK</language>
  <lastBuildDate>Mon, 19 Oct 2026 11:16:03 +0000</lastBuildDate>
  <atom:link href="https://irsaalsystems.com/feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title>Water Delivery Software in the UAE: A Buyer&#039;s Checklist for 5-Gallon Suppliers</title>
    <link>https://irsaalsystems.com/blog/water-delivery-software-uae-buyers-checklist</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/water-delivery-software-uae-buyers-checklist</guid>
    <pubDate>Fri, 02 Oct 2026 04:00:00 +0000</pubDate>
    <description>Eight questions to put to any water delivery software before a UAE supplier pays for it — starting with whether it can say, today, how many 5-gallon bottles each customer is holding.</description>
    <content:encoded><![CDATA[<p><strong>Choose water delivery software in the UAE by three things: whether it keeps a count of 5-gallon bottles per customer, whether it holds the deposit and the prepaid coupons against that customer, and whether it closes each driver's cash every day.</strong> Routes, invoices and reports come with almost every product. Those three are where a 5-gallon supplier actually loses money, and they are the ones to test first.</p>

<h2>1. Can it tell you how many bottles each customer is holding?</h2>
<p>Delivered and collected have to be recorded separately at every stop, with a running balance per customer. Ask to see the twenty customers holding the most bottles. If the product treats a bottle as an item sold, returns have nowhere to go and the count drifts within a month. See <a href="/blog/how-to-track-returnable-water-bottles">how to track returnable bottles</a>.</p>

<h2>2. Is the deposit tied to that count?</h2>
<p>A refundable deposit only protects you when it is compared with the bottles a customer holds. The software should show who is holding more bottles than their deposit covers, and work out a refund from what is actually returned.</p>

<h2>3. How does it handle coupon books?</h2>
<p>Most UAE suppliers sell prepaid coupons. Ask what happens to the money: is it kept as a balance the customer has paid ahead, with each delivery taken from it? A coupon count in a notebook and a cash figure in the accounts are two records that will disagree. See <a href="/blog/5-gallon-bottle-deposits-and-coupons">deposits and coupon books</a>.</p>

<h2>4. Does the driver app work in a basement?</h2>
<p>Towers mean car parks and service lifts with no signal. The app must record the stop offline and sync later — ask what happens to a delivery recorded with no connection.</p>

<h2>5. Is each driver's cash closed every day?</h2>
<p>Cash collected, bottles out, empties back and anything spent on the round, reconciled per driver each evening and approved by the office. See <a href="/blog/rider-cash-reconciliation-delivery-business">reconciling driver cash</a>.</p>

<h2>6. Can villas, towers and companies be priced and billed differently?</h2>
<p>A villa paying at the door, a tower flat on coupons and a company invoiced monthly are three kinds of customer on one truck. Look for a price per customer and payment terms per customer on one ledger.</p>

<h2>7. What does it do about VAT?</h2>
<p>VAT in the UAE is 5%. Ask exactly where tax appears: on which invoices, and whether the product files anything. Many delivery systems print a tax line and leave returns to your accounting software — which is fine, as long as you know.</p>

<h2>8. Which languages, and where is support?</h2>
<p>Ask which languages the office screens and the driver app run in, and what hours support keeps. An honest "no Arabic yet" is worth more than a vague "multi-language".</p>

<h2>How the usual options compare</h2>
<table>
  <thead><tr><th>Option</th><th>Good for</th><th>Falls short on</th></tr></thead>
  <tbody>
    <tr><td>Coupon books and a ledger</td><td>One route, one driver</td><td>Bottles per customer, money held ahead</td></tr>
    <tr><td>Spreadsheet</td><td>Monthly totals</td><td>Anything recorded at the door</td></tr>
    <tr><td>Accounting or POS software</td><td>Tax invoices</td><td>Returnable bottles, deposits, drivers</td></tr>
    <tr><td>Purpose-built water delivery software</td><td>Several routes and drivers</td><td>Check the eight questions above</td></tr>
  </tbody>
</table>

<h2>Where Irsaal fits</h2>
<p><a href="/water-delivery-software-in-uae">Irsaal for Water Delivery</a> has been open to UAE suppliers since October 2026. It keeps a bottle balance per customer, holds the deposit against it, records a coupon book as money paid in advance, closes each driver's cash daily and runs in AED. The office panel is in English and the driver app in English or Urdu — there is no Arabic interface yet. An order booked in the office can carry the 5% as a tax line; it does not file returns. Support is remote, from Pakistan. The trial is 14 days and takes no card.</p>

<h2>Frequently asked questions</h2>

<h3>What is the best water delivery software for a 5-gallon supplier in the UAE?</h3>
<p>The one that keeps a bottle balance per customer, holds deposits and prepaid coupons against that customer, works offline for drivers and closes each driver's cash daily. Test those four before anything else.</p>

<h3>Can water delivery software track 5-gallon bottle deposits?</h3>
<p>Purpose-built software can: it records bottles delivered and collected at every stop, keeps a running balance per customer and holds the refundable deposit against it.</p>

<h3>Does Irsaal work in the UAE?</h3>
<p>Yes. Since October 2026 a UAE business can open an account, which starts in AED. The panel is in English, the driver app in English or Urdu, and setup and support are remote.</p>]]></content:encoded>
    <category>Guides</category>
  </item>
  <item>
    <title>Bilty Software: How a Goods Transport Company Runs on It, From Counter to Delivery</title>
    <link>https://irsaalsystems.com/blog/bilty-software-goods-transport-company</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/bilty-software-goods-transport-company</guid>
    <pubDate>Fri, 02 Oct 2026 04:00:00 +0000</pubDate>
    <description>Bilty software books every consignment from one station to another, loads it onto a vehicle on a challan, collects To-Pay at the far end and keeps each station&#039;s cash — this is how the whole day runs on it.</description>
    <content:encoded><![CDATA[<p><strong>Bilty software is the system a goods transport company books every consignment in, from the counter where the bilty is written to the counter where the goods are handed over — and every rupee in between.</strong> Done properly it replaces four registers at every station (bookings, loading, arrivals and cash) with one record that every station reads, so the owner can see at any moment which goods are where, which vehicle is carrying them, and which station is holding whose money.</p>

<p>This article walks through a working day on it, station by station, and ends with the numbers an owner should be able to read off the screen every evening. If you are still deciding whether you need software at all, the last section is for you.</p>

<h2>What is bilty software, exactly?</h2>

<p>A goods transport company in Pakistan — a "goods adda", a forwarding agency, a cargo company — takes goods in at one of its own stations, carries them on a vehicle (usually hired) to another of its stations, and hands them to the receiver there. The paper that ties it together is the <a href="/blog/what-is-a-bilty">bilty</a>: the receipt and consignment note written at booking.</p>

<p>Bilty software is any system that writes that bilty and then follows it: onto a vehicle, off the vehicle, across the counter, and into the accounts. The difference between software that helps and software that does not is almost entirely in the "follows it" part. Printing a neat bilty is easy. Knowing, three weeks later, that bilty LHR-00412 arrived one carton short and its To-Pay freight was collected in Karachi on behalf of Lahore, is the actual job.</p>

<h2>Step 1 — The booking counter</h2>

<p>The sender arrives with goods. The clerk writes:</p>

<ul>
  <li>the sender and receiver, with phone numbers (and the receiver's CNIC if the company takes it at booking),</li>
  <li>each goods line: description, packing (carton, bundle, bag, drum), quantity and weight,</li>
  <li>the destination station, and whether the goods are collected there or delivered to a door,</li>
  <li>the freight, any extra charges (labour, packing, local pickup), and whether it is <strong>Paid</strong> now or <strong>To-Pay</strong> by the receiver.</li>
</ul>

<p>The software numbers the bilty with the station's own code — LHR-00413, KHI-02210 — so a number read over the phone says where it was booked, and prints it in copies: one for the sender, one that travels with the goods, one for the office. A QR code on the sender's copy opens the tracking page.</p>

<p>Two controls matter here. The package count on the bilty is what every later station will count against, so it has to be right. And a Paid bilty's freight goes straight into that station's cash, so the evening count at the counter starts from a figure the software already knows.</p>

<h2>Step 2 — Loading and the challan</h2>

<p>When a vehicle is going to Karachi, the loading clerk makes a <a href="/blog/loading-challan-kiraya-advance">loading challan</a>: the vehicle number, the driver, the kiraya (hire) agreed for the trip, the advance paid now — and the bilties going on board. Every bilty on the challan moves to "in transit" the moment the vehicle is dispatched, and the sender and receiver can be told by SMS that their goods have left.</p>

<p>The advance is paid from the loading station's cash; the balance (bakiya) is owed to the driver at the far end. Written on paper, this is where money goes missing: an advance paid twice, a balance paid at a station that never recorded it. On software the challan carries both figures, and the station that pays the balance does it against that challan.</p>

<h2>Step 3 — Receiving at the destination</h2>

<p>The vehicle arrives. The receiving station unloads it <em>bilty by bilty</em>, not by eye: for each one, all packages there, some short, some damaged, or the whole consignment missing. The driver's balance is cleared once the load is accepted. Receivers are told their goods have arrived.</p>

<p>This step is the one most registers skip, and it is the one that decides every claim that follows. A shortage recorded at unloading, with the vehicle and driver named, is a dispute about one trip. A shortage discovered when the receiver comes to collect, two days later, is an argument nobody can win. More on this in <a href="/blog/stop-cargo-loss-loading-receiving">stopping cargo loss between loading and delivery</a>.</p>

<h2>Step 4 — The delivery desk</h2>

<p>The receiver arrives with the bilty number and CNIC. The clerk finds the bilty, collects any <a href="/blog/to-pay-freight-collection">To-Pay freight</a>, and hands the goods over — or sends them out with a rider for door delivery, the rider collecting the To-Pay at the door into a ledger the office approves at the end of the day.</p>

<p>The rule the software enforces is simple and saves a fortune: goods with To-Pay outstanding are not handed over until it is paid.</p>

<h2>Step 5 — The accounts between stations</h2>

<p>Karachi has just collected Rs. 3,400 of freight that belongs to Lahore, which booked the goods. Karachi also paid a driver's Rs. 18,000 balance on a challan Lahore wrote. Neither is Karachi's money or Karachi's cost — and on paper, both are usually forgotten by the time anyone reconciles.</p>

<p>Bilty software keeps an <a href="/blog/inter-station-accounts-goods-transport">account between every pair of stations</a>: what each has collected or paid on the other's behalf. The stations settle it — weekly, usually — and the balance goes back to zero with a record of how.</p>

<h2>What should the owner see every evening?</h2>

<table>
  <thead>
    <tr><th>Question</th><th>Where the answer comes from</th></tr>
  </thead>
  <tbody>
    <tr><td>How many bilties did each station book today, and for how much freight?</td><td>The booking counter</td></tr>
    <tr><td>How much To-Pay freight is waiting to be collected, station by station?</td><td>Bilties arrived but not yet delivered</td></tr>
    <tr><td>Which vehicles are on the road, and what is each driver still owed?</td><td>Open loading challans</td></tr>
    <tr><td>How much cash should each station be holding right now?</td><td>Each station's cash book</td></tr>
    <tr><td>What does each station owe, or is owed by, the others?</td><td>The inter-station accounts</td></tr>
    <tr><td>Which consignments arrived short, damaged or missing this week?</td><td>Receiving records</td></tr>
  </tbody>
</table>

<p>If any of those takes a phone call to three stations to answer, the business is running on memory rather than on records.</p>

<h2>Do you actually need software?</h2>

<p>A single-route company with two stations and one clerk each can run on well-kept registers, and should, if the registers balance. Software starts paying for itself at the third station, or when vehicles are loaded for several destinations at once, or when To-Pay freight becomes a large share of income — because that is when money starts sitting at the wrong station, and a register cannot show it.</p>

<h2>Where Irsaal fits</h2>

<p><a href="/solutions/goods-transport">Irsaal for Goods Transport</a> is built around exactly this day: bilties with station codes and QR tracking, loading challans with kiraya and advance, receiving bilty by bilty, the delivery desk with To-Pay collection, a cash book per station and the inter-station accounts — plus SMS or WhatsApp alerts to senders and receivers and a website where customers track their bilty and send booking requests. Plans are sold by the number of stations; see <a href="/pricing?for=transport">pricing</a>, and the <a href="/get-started?for=transport">trial takes no card</a>.</p>

<h2>Frequently asked questions</h2>

<h3>What is bilty software?</h3>
<p>Bilty software is a system for goods transport companies that writes the bilty (the consignment receipt) at the booking counter and then tracks that consignment onto a vehicle, through unloading and across the delivery counter, together with the freight, To-Pay collection and each station's cash.</p>

<h3>Is bilty software the same as courier software?</h3>
<p>No. Courier software handles thousands of small parcels delivered to individual doors. Bilty software handles consignments booked between a transporter's own stations, carried on hired vehicles and usually collected at the destination office, with Paid or To-Pay freight.</p>

<h3>Can each station see only its own bookings?</h3>
<p>In a properly built system, yes: staff are tied to their station and see its bookings, arrivals and cash, while the owner sees every station together.</p>

<h3>How do customers track a bilty?</h3>
<p>The bilty number (or a QR code on the receipt) opens a tracking page showing when the goods were booked, dispatched, arrived and delivered. Good systems also send an SMS or WhatsApp message at each of those steps.</p>

<h3>Does it work without a computer at every station?</h3>
<p>Cloud-based bilty software runs in a web browser, so a station can work from a laptop, a desktop or even a phone, and every station sees the same records the moment they are saved.</p>]]></content:encoded>
    <category>Goods Transport</category>
  </item>
  <item>
    <title>5-Gallon Bottle Deposits and Coupon Books: How to Keep Both Counts Straight</title>
    <link>https://irsaalsystems.com/blog/5-gallon-bottle-deposits-and-coupons</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/5-gallon-bottle-deposits-and-coupons</guid>
    <pubDate>Thu, 01 Oct 2026 04:00:00 +0000</pubDate>
    <description>A 5-gallon customer carries two balances: bottles of yours they are holding, and money they have paid you ahead. Mixing the two is how a supplier loses both.</description>
    <content:encoded><![CDATA[<p><strong>Keep two separate balances for every 5-gallon customer: the bottles of yours they are holding, and the money they have paid you in advance. The deposit belongs to the first; the coupon book belongs to the second.</strong> Most disputes in a water round — "I returned that bottle", "I still had six coupons" — come from one of the two being kept in somebody's head.</p>

<h2>What is the deposit actually for?</h2>
<p>The bottle is yours. It is expensive, it goes out full and it is supposed to come back. The refundable deposit is what makes a lost bottle the customer's cost rather than yours — but only if you know how many bottles the customer is holding. A deposit taken for two bottles from a customer now holding five protects two of them.</p>

<h2>What is a coupon book, in your accounts?</h2>
<p>A coupon book is a payment in advance. The customer has given you money for water you have not delivered yet; until you deliver it, that money is held for them. It is not a sale on the day the book is bought, and it is not a count of paper slips — slips get lost, and a customer who has lost theirs has still paid.</p>

<h2>The three counts, side by side</h2>
<table>
  <thead><tr><th>Count</th><th>Goes up when</th><th>Goes down when</th><th>What it tells you</th></tr></thead>
  <tbody>
    <tr><td>Bottles with the customer</td><td>A full bottle is delivered</td><td>An empty is collected</td><td>What you are owed back in bottles</td></tr>
    <tr><td>Deposit held</td><td>A deposit is paid</td><td>It is refunded, or a lost bottle is charged to it</td><td>How many of those bottles are covered</td></tr>
    <tr><td>Money paid ahead</td><td>A coupon book is bought</td><td>A delivery is billed</td><td>What you still owe the customer in water</td></tr>
  </tbody>
</table>

<h2>How do you record it at the door?</h2>
<ol>
  <li><strong>Delivered.</strong> How many full bottles went in.</li>
  <li><strong>Collected.</strong> How many empties came out — a separate number, not "the same".</li>
  <li><strong>Paid.</strong> Cash or transfer taken now, if any. A customer on coupons pays nothing at the door; the delivery is taken from what they paid ahead.</li>
</ol>
<p>Three numbers per stop. A system that captures only "delivered" will have you reconciling bottles and coupons from memory at the end of the month.</p>

<h2>What happens when a customer leaves?</h2>
<p>Count the bottles they return, refund the deposit for those, charge any that are missing, and hand back whatever is left of the money they paid ahead. All three figures should come off the customer's own record, in front of them.</p>

<h2>Where Irsaal fits</h2>
<p><a href="/gulf">Irsaal</a> keeps exactly these balances. Every bottle is a balance against the customer holding it — the panel calls it the 19 litre bottle, the 5-gallon bottle's metric name — and the deposit is held against that count. A coupon book is recorded as a payment in advance: each delivery's bill is taken from it, the customer's ledger shows what is still held, and whatever is left can be refunded when they close. It tracks the money, not the paper coupons, so a supplier who wants to count slips will still count slips. It has been open to businesses in the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain and Oman since October 2026.</p>

<h2>Frequently asked questions</h2>

<h3>Is a bottle deposit income?</h3>
<p>No. A refundable deposit is money you are holding against a bottle the customer has, and it goes back when the bottle does. Treat it as held, not earned.</p>

<h3>How should a water supplier record coupon book sales?</h3>
<p>As money paid in advance by that customer. Each delivery is then taken from the balance, so at any moment you can see how much water you still owe each customer.</p>

<h3>What if a customer holds more bottles than their deposit covers?</h3>
<p>Then the extra bottles are unprotected. The record should show it, so you can take a further deposit or collect bottles before the gap becomes a loss.</p>]]></content:encoded>
    <category>Operations</category>
  </item>
  <item>
    <title>What Is a Bilty? Copies, Charges, Paid and To-Pay — Explained</title>
    <link>https://irsaalsystems.com/blog/what-is-a-bilty</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/what-is-a-bilty</guid>
    <pubDate>Thu, 01 Oct 2026 04:00:00 +0000</pubDate>
    <description>A bilty is the receipt a goods transport company writes when it takes your goods: proof of what was handed over, where it is going, what the freight is and who pays it.</description>
    <content:encoded><![CDATA[<p><strong>A bilty is the receipt a goods transport company gives you when it takes your goods: written proof of what was handed over, from which station to which, what the freight is, and whether you have paid it or the receiver will.</strong> It is the consignment note of Pakistani road freight. Everything that happens to the goods afterwards — loading, unloading, a claim for damage, the handover at the other end — is checked against it.</p>

<h2>What must a bilty show?</h2>

<p>A bilty that will stand up when something goes wrong carries, at minimum:</p>

<table>
  <thead>
    <tr><th>Field</th><th>Why it matters</th></tr>
  </thead>
  <tbody>
    <tr><td>Bilty number and date</td><td>The one reference everyone uses — sender, receiver, both stations. A station code in the number (LHR-00413) tells anyone where it was booked.</td></tr>
    <tr><td>From station and to station</td><td>Where the transporter's responsibility starts and ends.</td></tr>
    <tr><td>Sender and receiver, with phone numbers</td><td>Who handed the goods over and who may collect them.</td></tr>
    <tr><td>Each goods line: description, packing, number of packages, weight</td><td>The count every later station checks against. "5 cartons crockery, 50 kg" is a checkable promise; "goods" is not.</td></tr>
    <tr><td>Declared value (optional)</td><td>What the sender says the goods are worth — the basis of any claim.</td></tr>
    <tr><td>Freight and extra charges</td><td>Labour, packing, local pickup or door delivery charged separately.</td></tr>
    <tr><td>Paid or To-Pay</td><td>Whether the freight was paid at booking or is due from the receiver.</td></tr>
    <tr><td>Collection at the office, or door delivery</td><td>What the receiver should expect.</td></tr>
  </tbody>
</table>

<h2>Why does a bilty come in copies?</h2>

<p>Because three different people need it in three different places:</p>

<ul>
  <li><strong>The sender's copy</strong> is their receipt — proof they handed the goods over, and the number they give the receiver.</li>
  <li><strong>The goods copy</strong> travels with the consignment, so whoever unloads it can match packages to paper.</li>
  <li><strong>The office copy</strong> stays at the booking station for the accounts.</li>
</ul>

<p>Software-printed bilties keep the same three copies and add a QR code to the sender's, which opens the tracking page for that bilty — so the receiver does not have to phone the station to ask where the goods are.</p>

<h2>What is the difference between Paid and To-Pay?</h2>

<p><strong>Paid</strong> means the sender pays the freight at booking. The money is in the booking station's cash that day, and the receiver owes nothing at collection.</p>

<p><strong>To-Pay</strong> means the receiver pays the freight when collecting the goods at the destination. It is common in trade — a wholesaler sending stock to a shopkeeper who pays on arrival — and it is the single biggest source of money going astray in a transport company, because the freight is earned by one station and collected by another. See <a href="/blog/to-pay-freight-collection">how to collect every rupee of To-Pay</a>.</p>

<h2>What happens if the bilty is lost?</h2>

<p>The receiver can usually still collect, but the transporter should be stricter, not looser: the bilty number (the sender can read it from their copy or the SMS), the receiver's CNIC matching the name on the bilty, and a signature on the handover. Goods handed to whoever turns up with a story are goods the transporter pays for when the real receiver arrives.</p>

<h2>What should a sender check before leaving the counter?</h2>

<ol>
  <li>The number of packages on the bilty matches what you handed over.</li>
  <li>The receiver's name and phone number are correct — a wrong digit means no arrival SMS.</li>
  <li>Paid or To-Pay is marked the way you agreed.</li>
  <li>Anything fragile or valuable is described, and its value declared if you want to claim for it.</li>
</ol>

<h2>How do transport companies issue bilties today?</h2>

<p>Most still write them by hand in carbon books, which works until the company has several stations and nobody can say, without phoning around, where a given bilty is. Bilty software prints the same bilty, numbers it by station, and follows it through loading, arrival and delivery — see <a href="/blog/bilty-software-goods-transport-company">how a transport company runs on bilty software</a>. <a href="/solutions/goods-transport">Irsaal for Goods Transport</a> is one such system, built for Pakistani transporters.</p>

<h2>Frequently asked questions</h2>

<h3>What is a bilty in transport?</h3>
<p>A bilty is the receipt and consignment note a goods transport company writes when it accepts goods, recording the sender, receiver, stations, packages, freight and whether the freight is Paid or To-Pay.</p>

<h3>What does To-Pay mean on a bilty?</h3>
<p>To-Pay means the freight has not been paid by the sender and must be paid by the receiver when collecting the goods at the destination station.</p>

<h3>Is a bilty a legal document?</h3>
<p>It is the written record of the contract of carriage between the sender and the transporter, and it is the document both sides rely on if goods are lost, short or damaged. For a specific legal question, ask a lawyer.</p>

<h3>How do I track my bilty?</h3>
<p>Ask the transporter for its tracking page, or scan the QR code on the receipt if there is one, and enter the bilty number. Many transporters also send an SMS when the goods are dispatched and when they arrive.</p>

<h3>Can someone else collect my goods with the bilty?</h3>
<p>Only if the transporter allows it. Careful transporters hand goods over against the bilty number and the CNIC of the receiver named on the bilty, and ask for a signature.</p>]]></content:encoded>
    <category>Goods Transport</category>
  </item>
  <item>
    <title>Water Delivery Software in Saudi Arabia: What to Check Before You Choose</title>
    <link>https://irsaalsystems.com/blog/water-delivery-software-saudi-arabia</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/water-delivery-software-saudi-arabia</guid>
    <pubDate>Wed, 30 Sep 2026 04:00:00 +0000</pubDate>
    <description>Long drives, villas a district at a time, a summer that doubles the load — and a tax system that wants e-invoices. What a Saudi water supplier should ask of delivery software.</description>
    <content:encoded><![CDATA[<p><strong>A water supplier in Saudi Arabia should check delivery software on four things: a bottle balance per customer, a record of what each route took, a daily close of each driver's cash — and, separately, how tax invoices are issued, because a delivery system and a ZATCA e-invoicing system are not the same thing.</strong> Most products are strong on one side and silent on the other. Knowing which is which before you buy saves a second purchase.</p>

<h2>Why are Saudi rounds different?</h2>
<p>Distance and season. Riyadh, Jeddah and the Dammam–Khobar–Dhahran area are spread out, and a round is long drives between clusters of villas, compounds, mosques and offices. Summer asks for far more water than winter. A truck loaded on a guess either comes back half full or runs out two districts early, and a bottle that does not come back is a long way to go and ask for.</p>

<h2>What should the software keep for you?</h2>
<table>
  <thead><tr><th>Need</th><th>What to ask to see</th></tr></thead>
  <tbody>
    <tr><td>Bottles per customer</td><td>Delivered and collected at each stop, and a running balance per customer</td></tr>
    <tr><td>Deposit against bottles</td><td>Customers holding more bottles than their deposit covers</td></tr>
    <tr><td>Route history</td><td>What each route took last week, and the same week last year</td></tr>
    <tr><td>Driver cash</td><td>Each driver's collections closed and approved every evening</td></tr>
    <tr><td>Contract customers</td><td>Compounds and offices on their own price, invoiced weekly or monthly</td></tr>
    <tr><td>Offline app</td><td>A stop recorded with no signal, synced later</td></tr>
  </tbody>
</table>

<h2>Where does ZATCA e-invoicing fit?</h2>
<p>VAT in Saudi Arabia is 15%, and a business registered for it issues its tax invoices through ZATCA's e-invoicing system (Fatoora). That is a job for software built and approved for it. A delivery system may print an invoice with a tax line; that does not make it an e-invoicing system. Ask the vendor plainly, and plan for the two to sit side by side if the answer is no: the delivery system for bottles, deposits and driver cash, the accounting system for tax invoices.</p>

<h2>Which languages do your drivers read?</h2>
<p>Ask what the driver app runs in. A driver who reads the screen in the language he reads fastest makes fewer mistakes at the door. See <a href="/blog/urdu-rider-app-gulf-delivery-drivers">a delivery app your drivers can read</a>.</p>

<h2>Where Irsaal fits — and where it does not</h2>
<p><a href="/water-delivery-software-in-saudi-arabia">Irsaal for Water Delivery</a> has been open to Saudi businesses since October 2026. It does the delivery side: a bottle balance per customer, deposits held against it, routes and their history, an offline driver app in English or Urdu, daily driver settlement, a price per customer and weekly or monthly payment plans, in SAR. It is not a ZATCA e-invoicing system — an order booked in the office can carry the 15% as a tax line, and that is all — so a VAT-registered business needs its accounting software for tax invoices. There is no Arabic interface yet, and support is remote, from Pakistan. If either of those rules it out, it is better to know now.</p>

<h2>Frequently asked questions</h2>

<h3>Is there water delivery software for suppliers in Saudi Arabia?</h3>
<p>Yes. Irsaal for Water Delivery has been open to Saudi businesses since October 2026, in SAR, with an office panel in English and a driver app in English or Urdu.</p>

<h3>Does water delivery software issue ZATCA e-invoices?</h3>
<p>Not usually, and Irsaal does not. A delivery system records bottles, deposits and cash; tax invoices that must go through ZATCA's Fatoora system are issued from accounting software built for it.</p>

<h3>How do I plan water loads for a Saudi summer?</h3>
<p>From your own record: what each route took in the same weeks last year and in the last fortnight. See <a href="/blog/summer-demand-planning-water-delivery-gulf">planning for summer demand</a>.</p>]]></content:encoded>
    <category>Guides</category>
  </item>
  <item>
    <title>Loading Challan Explained: Kiraya, Advance and the Driver&#039;s Balance</title>
    <link>https://irsaalsystems.com/blog/loading-challan-kiraya-advance</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/loading-challan-kiraya-advance</guid>
    <pubDate>Wed, 30 Sep 2026 04:00:00 +0000</pubDate>
    <description>A loading challan lists the bilties on a hired vehicle and settles what the driver is paid: kiraya agreed, advance at loading, balance at unloading. Here is how to keep it straight.</description>
    <content:encoded><![CDATA[<p><strong>A loading challan is the sheet that goes with a vehicle: which bilties are on it, and what the driver is paid — the kiraya agreed for the trip, the advance paid at loading, and the balance owed on arrival.</strong> Kiraya minus advance is the balance, and the balance is paid by the destination station once the load has been checked. Keep those three numbers on one record and most driver disputes never start.</p>

<h2>What goes on a loading challan?</h2>

<ul>
  <li><strong>The vehicle</strong> — registration number and type (Mazda, 22-wheeler, container).</li>
  <li><strong>The driver</strong> — name, phone and CNIC, and the owner or broker if the vehicle is hired through one.</li>
  <li><strong>The route</strong> — loading station and destination station.</li>
  <li><strong>The bilties</strong> — every consignment on board, with its package count.</li>
  <li><strong>The money</strong> — kiraya for the trip, advance paid now, balance due at the far end.</li>
</ul>

<h2>How are kiraya, advance and balance worked out?</h2>

<table>
  <thead>
    <tr><th>Item</th><th>Example</th><th>Paid by</th><th>When</th></tr>
  </thead>
  <tbody>
    <tr><td>Kiraya (hire for the trip)</td><td>Rs. 60,000</td><td>—</td><td>Agreed before loading</td></tr>
    <tr><td>Advance</td><td>Rs. 25,000</td><td>Loading station</td><td>At dispatch</td></tr>
    <tr><td>Balance (bakiya)</td><td>Rs. 35,000</td><td>Destination station</td><td>After unloading and checking</td></tr>
  </tbody>
</table>

<p>Two things make this go wrong on paper. The balance is paid by a station that did not write the challan, so it has to trust a phone call about the amount. And if the load arrives short, the balance is exactly the money you would hold back — but only if the station paying it knows the shortage before it pays.</p>

<h2>Step by step: from loading to settling the driver</h2>

<ol>
  <li><strong>Agree the kiraya</strong> and write it on the challan before loading starts. An amount agreed afterwards is an amount argued about.</li>
  <li><strong>Load bilty by bilty</strong>, ticking each consignment and its package count onto the challan. Goods loaded without a line on the challan are goods nobody is responsible for.</li>
  <li><strong>Pay the advance</strong> from the loading station's cash, against the challan, and have the driver sign.</li>
  <li><strong>Dispatch.</strong> Every bilty on the challan is now in transit; senders and receivers can be told.</li>
  <li><strong>Receive at the destination</strong>, bilty by bilty: all there, short, damaged or missing.</li>
  <li><strong>Pay the balance</strong> from the destination station's cash, against the same challan — less anything agreed for shortage or damage.</li>
  <li><strong>Settle between stations.</strong> The destination paid a cost that belongs to the loading station's trip; that amount goes into the <a href="/blog/inter-station-accounts-goods-transport">account between the two stations</a>.</li>
</ol>

<h2>What if the driver needs more money on the road?</h2>

<p>It happens — a breakdown, a toll, a delay. Record it as a second advance on the same challan, paid by whichever station paid it. The balance at the far end then drops by that much automatically. The failure to avoid is money handed over on the road with no record, found out when the driver asks for the full balance at unloading.</p>

<h2>How should shortages affect the driver's payment?</h2>

<p>Decide the rule once, write it down, and tell every driver before loading: what is deducted for a missing carton, what for a damaged one, and who decides. The receiving station records shortages against the challan before paying the balance, so the deduction is a matter of record rather than of who shouts loudest. Recording receiving properly is covered in <a href="/blog/stop-cargo-loss-loading-receiving">stopping cargo loss between loading and delivery</a>.</p>

<h2>Doing it in software</h2>

<p>A good system makes the challan the only place a driver's money can be paid from: the advance at the loading station, extra advances wherever they happen, the balance at the destination, each from that station's cash and each against the challan, with the shortage recorded before the balance is paid. <a href="/solutions/goods-transport">Irsaal for Goods Transport</a> works this way — challans for hired vehicles with kiraya and advance, receiving bilty by bilty, and the driver's balance cleared at unloading, with the inter-station account updated on its own.</p>

<h2>Frequently asked questions</h2>

<h3>What is a loading challan?</h3>
<p>A loading challan is the document for one vehicle trip in goods transport: it lists every bilty loaded onto the vehicle and records the driver, the kiraya agreed, the advance paid at loading and the balance due at the destination.</p>

<h3>What is kiraya in goods transport?</h3>
<p>Kiraya is the hire charge agreed with the driver or vehicle owner for carrying a load from one station to another. It is usually paid as an advance at loading and a balance at unloading.</p>

<h3>Who pays the driver's balance?</h3>
<p>Normally the destination station pays the balance after the load has been unloaded and checked. Because it pays a cost of the loading station's trip, the amount is then settled between the two stations.</p>

<h3>Can one challan carry bilties for several destinations?</h3>
<p>A challan normally covers one trip from one station to one destination. A vehicle dropping at several stations is usually written as one challan per leg, so each station receives and pays against its own.</p>

<h3>What is the difference between a bilty and a loading challan?</h3>
<p>A bilty is one consignment from one sender to one receiver. A loading challan is one vehicle trip, carrying many bilties, and it also settles what the driver is paid.</p>]]></content:encoded>
    <category>Goods Transport</category>
  </item>
  <item>
    <title>Gas Cylinder Delivery Software for LPG Distributors in the Gulf</title>
    <link>https://irsaalsystems.com/blog/lpg-gas-cylinder-delivery-software-gulf</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/lpg-gas-cylinder-delivery-software-gulf</guid>
    <pubDate>Tue, 29 Sep 2026 04:00:00 +0000</pubDate>
    <description>A cylinder round is an exchange business: a full one out, an empty one back, a deposit on each. What software for an LPG distributor in the UAE, Saudi Arabia, Bahrain or Oman has to get right.</description>
    <content:encoded><![CDATA[<p><strong>Gas cylinder delivery software has to treat a refill as an exchange, not a sale: a full cylinder goes out, an empty one comes back, and a deposit is held against every cylinder a customer keeps.</strong> Software built for a shop sells the cylinder as a product and has lost track of it by the end of the week. That is the first thing to test, whatever country you deliver in.</p>

<h2>Why is a cylinder round different from other deliveries?</h2>
<p>Three things at once. The cylinder is yours and it is expensive. It comes in sizes — 11 kg, 22 kg and 44 kg are the common ones in the UAE and Oman — each with its own refill price and deposit. And your stock is two numbers, not one: full and empty. A distributor who cannot say how many full cylinders are on the floor and how many empties are out with customers is guessing the next order from the filling plant.</p>

<h2>What to check before you buy</h2>
<table>
  <thead><tr><th>Need</th><th>What to ask to see</th></tr></thead>
  <tbody>
    <tr><td>A rate per size</td><td>A flat on the 11 kg rate and a restaurant on the 44 kg rate, each billed and charged a deposit at its own price</td></tr>
    <tr><td>Full and empty stock</td><td>Stock split into full and empty — in the store, at the plant, with customers and with drivers — moved by every delivery and return</td></tr>
    <tr><td>Refill as an exchange</td><td>One step that sends a full cylinder and brings an empty back</td></tr>
    <tr><td>Deposits</td><td>Customers holding more cylinders than their deposit covers</td></tr>
    <tr><td>Commercial accounts</td><td>Restaurants and staff accommodation on credit, settled weekly or monthly</td></tr>
    <tr><td>Driver settlement</td><td>Each driver's cash and cylinders reconciled at the end of the day</td></tr>
  </tbody>
</table>

<h2>Restaurants, cafeterias and camps</h2>
<p>Commercial customers change the shape of the business: larger cylinders, several at a time, weekly swaps and a monthly bill. They should carry their own price, their own cylinder balance and their own payment terms, while households pay per refill at the door.</p>

<h2>What goes missing, and where?</h2>
<p>Cylinders go missing in three places: with a customer who moved, on a truck at the end of a long day, and between the store and the filling plant. A count that names each of those places — and the person responsible in each — is what turns "we are short" into "these four, with this customer".</p>

<h2>Where Irsaal fits</h2>
<p><a href="/lpg-delivery-software-in-uae">Irsaal for LPG Cylinder Delivery</a> has been open to distributors in the Gulf since October 2026, with pages for the <a href="/lpg-delivery-software-in-uae">UAE</a>, <a href="/lpg-delivery-software-in-saudi-arabia">Saudi Arabia</a>, <a href="/lpg-delivery-software-in-bahrain">Bahrain</a> and <a href="/lpg-delivery-software-in-oman">Oman</a>. It counts cylinders full and empty wherever they are, handles a refill as an exchange, holds the deposit against each cylinder a customer keeps, gives each size its own refill price and deposit through rate cards, puts commercial customers on weekly or monthly terms, and gives drivers an offline app in English or Urdu with a Bluetooth receipt. It is not a regulator's or a filling plant's system, there is no Arabic interface yet, and support is remote, from Pakistan.</p>

<h2>Frequently asked questions</h2>

<h3>Is there software for an LPG distributor in the UAE or Oman?</h3>
<p>Yes. Irsaal for LPG Cylinder Delivery has been open to Gulf distributors since October 2026: full and empty stock, refill exchange, deposits, a rate per cylinder size and an offline driver app.</p>

<h3>How do I track which customer has which gas cylinder?</h3>
<p>Record every full cylinder delivered and every empty collected at the door, so each customer has a running cylinder balance, with the deposit they paid held against it.</p>

<h3>Can one system price 11 kg, 22 kg and 44 kg cylinders differently?</h3>
<p>It should. Each size needs its own refill price and its own deposit, and a customer who was agreed a different price needs to be billed at theirs.</p>]]></content:encoded>
    <category>Guides</category>
  </item>
  <item>
    <title>To-Pay Freight: How to Collect Every Rupee Before the Goods Leave the Godown</title>
    <link>https://irsaalsystems.com/blog/to-pay-freight-collection</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/to-pay-freight-collection</guid>
    <pubDate>Tue, 29 Sep 2026 04:00:00 +0000</pubDate>
    <description>To-Pay freight is earned by one station and collected by another, which is why it goes missing. Five rules that keep it where it belongs.</description>
    <content:encoded><![CDATA[<p><strong>To-Pay freight is collected reliably by one rule above all others: goods with To-Pay outstanding do not leave the godown until it is paid — and the station collecting it records it as money held for the station that booked it.</strong> Almost every To-Pay loss comes from breaking one of those two halves: goods handed over "on trust", or freight collected and never passed back.</p>

<h2>Why is To-Pay harder than Paid?</h2>

<p>A Paid bilty is simple: the booking station takes the money on the day, and it is in that station's cash by evening. A To-Pay bilty is earned at one station and collected at another, days later, by a different clerk, from a person the booking station never met. Three things can go wrong:</p>

<ul>
  <li>the goods are handed over without the freight being collected,</li>
  <li>the freight is collected but recorded as the destination station's own income,</li>
  <li>the goods sit uncollected for weeks, taking up godown space, and are eventually handed over at a discount nobody approved.</li>
</ul>

<h2>Rule 1 — No freight, no goods</h2>

<p>The delivery desk checks the bilty before anything moves: if To-Pay is outstanding, it is collected first. No exceptions for "regular customers" unless the owner has put that customer on credit terms, in writing, with a limit. Good software makes this automatic: the handover cannot be recorded while To-Pay is outstanding.</p>

<h2>Rule 2 — Hand over against the bilty and the CNIC</h2>

<p>The receiver named on the bilty, with a matching CNIC, signs for the goods. This is not bureaucracy: the freight has just been paid by somebody, and if it was the wrong somebody, the real receiver will arrive tomorrow asking for goods you no longer have.</p>

<h2>Rule 3 — Money collected for another station is not yours</h2>

<p>When Karachi collects Rs. 4,200 To-Pay on a bilty Lahore booked, Karachi is holding Lahore's money. Record it that way — as a credit in the <a href="/blog/inter-station-accounts-goods-transport">account between Karachi and Lahore</a> — and settle it weekly. A destination station that counts To-Pay as its own income looks wonderfully profitable and makes the booking stations look like they are losing money on every route.</p>

<h2>Rule 4 — Tell the receiver the goods have arrived, and when storage starts</h2>

<p>Uncollected goods are the slow leak in To-Pay. An arrival SMS the same day the vehicle is unloaded brings most receivers in within a day or two. State your free storage period on the bilty (seven days is common) and what is charged after it, and apply it. Goods that sit for a month are goods whose freight you will end up discounting to get rid of them.</p>

<h2>Rule 5 — Door delivery collects at the door</h2>

<p>If a rider delivers a To-Pay consignment to the door, the rider collects the freight there, into a ledger the office approves at the end of the day. The rider hands over cash for exactly what the ledger says was collected — no "I'll bring it tomorrow".</p>

<h2>What should the To-Pay report show?</h2>

<table>
  <thead>
    <tr><th>Report</th><th>What it tells you</th><th>How often</th></tr>
  </thead>
  <tbody>
    <tr><td>To-Pay outstanding by destination station</td><td>How much freight is sitting in each godown waiting for receivers</td><td>Daily</td></tr>
    <tr><td>Arrived, not collected, older than 7 days</td><td>Who to phone today, before storage charges become a dispute</td><td>Daily</td></tr>
    <tr><td>To-Pay collected on another station's behalf</td><td>What each station owes the others this week</td><td>Weekly</td></tr>
    <tr><td>To-Pay collected by riders, awaiting approval</td><td>Cash still in riders' hands</td><td>End of every day</td></tr>
  </tbody>
</table>

<h2>Should you offer credit to regular receivers?</h2>

<p>Some traders receive stock every week and will not queue to pay each bilty. Offering them credit is a business decision, not a clerk's: put them on an account with a limit, bill weekly, and keep To-Pay rules for everyone else. What must not happen is informal credit — the clerk who "knows them" — which is invisible until the customer stops paying.</p>

<h2>Doing it in software</h2>

<p><a href="/solutions/goods-transport">Irsaal for Goods Transport</a> enforces these rules as the default: the delivery desk collects To-Pay before the handover, finds a bilty by number or CNIC, sends arrival SMS or WhatsApp alerts, has riders collect To-Pay at the door into a daily ledger the office approves, and posts To-Pay collected for another station into the account between the two. See <a href="/pricing?for=transport">pricing</a>.</p>

<h2>Frequently asked questions</h2>

<h3>What is To-Pay freight?</h3>
<p>To-Pay freight is transport charges that the receiver pays when collecting the goods at the destination, instead of the sender paying at booking.</p>

<h3>Who does To-Pay money belong to?</h3>
<p>It belongs to the station that booked the consignment and earned the freight. The destination station that collects it is holding it on that station's behalf until they settle.</p>

<h3>Can goods be handed over before To-Pay is paid?</h3>
<p>Only if the owner has put that receiver on agreed credit terms. Otherwise the freight should be collected before the goods leave the godown.</p>

<h3>What if the receiver never collects the goods?</h3>
<p>Send an arrival message the day they arrive, charge storage after a stated free period, and phone anyone whose goods are older than a week. Goods left for months should be dealt with under the terms printed on the bilty.</p>]]></content:encoded>
    <category>Goods Transport</category>
  </item>
  <item>
    <title>How to Reconcile Driver Cash Every Day in a Delivery Business</title>
    <link>https://irsaalsystems.com/blog/rider-cash-reconciliation-delivery-business</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/rider-cash-reconciliation-delivery-business</guid>
    <pubDate>Mon, 28 Sep 2026 04:00:00 +0000</pubDate>
    <description>Cash collected on a round is the largest uncontrolled sum in most delivery businesses. A five-step daily close that finds a shortfall the evening it happens.</description>
    <content:encoded><![CDATA[<p><strong>Close every driver's cash every day: what the round collected, less what the driver spent on it, against what was handed in — approved by somebody in the office before the money is counted as yours.</strong> A shortfall found the same evening is a conversation. One found at the end of the month is a loss nobody can explain.</p>

<h2>Why does it have to be daily?</h2>
<p>Because the driver is holding two things that are yours all day — cash and empties — and memory lasts about a day. By the next morning nobody remembers which door paid in coins and which promised to pay tomorrow.</p>

<h2>The five-step close</h2>
<ol>
  <li><strong>What did the round collect?</strong> Every payment taken at a door, listed by customer, split into cash and bank transfer. Transfers never passed through the driver's hands.</li>
  <li><strong>What was spent on the round?</strong> Fuel, a puncture, parking. Spent out of the cash, so it comes off what is handed in — recorded when it is spent, with what it was for.</li>
  <li><strong>What should be handed in?</strong> Cash collected, less cash spent. That is the figure to count against.</li>
  <li><strong>What was handed in?</strong> The driver declares it; the office counts it. Any difference stays against the driver by name, not in a general "shortage" account.</li>
  <li><strong>Who approved it?</strong> The money moves into the cash drawer or the bank only when somebody in the office approves the day. Until then it is still on the driver.</li>
</ol>

<h2>What about the empties?</h2>
<p>Close them with the cash. Bottles or cylinders the driver collected are in his custody until they are counted back into the store. A day that balances in money and is twenty empties short has not balanced.</p>

<h2>What if the driver never hands the day over?</h2>
<p>It happens: a phone left at home, a driver on leave, one who has gone. The day must not be left open, because money that nobody has handed over is money nobody has counted. The office needs to be able to record the hand-over itself — what was actually received, with the name of whoever recorded it — and then approve it like any other day. And a day handed over last week that nobody approved should stay in front of the office until somebody does.</p>

<h2>What to look at every week</h2>
<table>
  <thead><tr><th>Check</th><th>What it catches</th></tr></thead>
  <tbody>
    <tr><td>Days not handed over</td><td>Cash still in a pocket</td></tr>
    <tr><td>Days handed over, not approved</td><td>Cash in the office that the books do not show</td></tr>
    <tr><td>Shortfalls by driver</td><td>A pattern, rather than one bad evening</td></tr>
    <tr><td>Expenses by driver</td><td>Fuel that does not match the route</td></tr>
  </tbody>
</table>

<h2>Where Irsaal fits</h2>
<p>In <a href="/features">Irsaal</a> every payment a rider takes goes onto that rider's own ledger. Expenses recorded on the round come off the cash they owe. The rider submits the day from the app — including any earlier day they missed — and the office approves it, choosing which cash and bank accounts the money lands in; a shortfall stays against the rider. If the rider cannot submit a day, the office records the hand-over itself, and any day waiting for approval is listed with how long it has waited. Irsaal was built on a water round in Pakistan, and has been open to businesses in the <a href="/gulf">Gulf</a> since October 2026.</p>

<h2>Frequently asked questions</h2>

<h3>How often should a delivery driver's cash be reconciled?</h3>
<p>Every day, at the end of the round. A weekly or monthly close finds the difference too late for anybody to explain it.</p>

<h3>Should a driver's fuel come out of the cash collected?</h3>
<p>It can, as long as it is recorded when it is spent and comes off the figure the driver has to hand in. What must not happen is an unrecorded deduction.</p>

<h3>What should happen to a cash shortfall?</h3>
<p>It should stay against the driver by name until it is cleared, so that a pattern is visible and a single bad evening is not written off unseen.</p>]]></content:encoded>
    <category>Operations</category>
  </item>
  <item>
    <title>Inter-Station Accounts: How Transport Addas Settle What They Owe Each Other</title>
    <link>https://irsaalsystems.com/blog/inter-station-accounts-goods-transport</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/inter-station-accounts-goods-transport</guid>
    <pubDate>Mon, 28 Sep 2026 04:00:00 +0000</pubDate>
    <description>When one station collects freight or pays a driver on another&#039;s behalf, it creates a balance between them. Here is how to keep that balance visible and settle it every week.</description>
    <content:encoded><![CDATA[<p><strong>An inter-station account is a running balance between two of your stations, recording money one collected or paid on the other's behalf — and settling it every week is how a multi-station transport company knows each station's real profit.</strong> Without it, the destination station looks rich (it keeps To-Pay freight that others earned) and the booking stations look like they lose money on every route.</p>

<h2>What creates a balance between two stations?</h2>

<table>
  <thead>
    <tr><th>What happens</th><th>Example</th><th>Who owes whom</th></tr>
  </thead>
  <tbody>
    <tr><td>To-Pay freight collected at the destination</td><td>Karachi collects Rs. 4,200 on a bilty Lahore booked</td><td>Karachi owes Lahore Rs. 4,200</td></tr>
    <tr><td>Driver's balance paid at the destination</td><td>Karachi pays Rs. 35,000 balance on Lahore's challan</td><td>Lahore owes Karachi Rs. 35,000</td></tr>
    <tr><td>Extra advance paid on the road by another station</td><td>Multan pays Rs. 5,000 to a Lahore–Karachi driver after a breakdown</td><td>Lahore owes Multan Rs. 5,000</td></tr>
    <tr><td>Door delivery charges collected for the booking station</td><td>A rider in Karachi collects a delivery charge Lahore invoiced</td><td>Karachi owes Lahore the charge</td></tr>
  </tbody>
</table>

<p>Net them off and you have one figure per pair of stations: in the example above, Lahore owes Karachi Rs. 30,800.</p>

<h2>Why does it matter if all the money ends up in one company anyway?</h2>

<p>Because the company is run by station managers, and a station manager is judged — and often paid — on his station's results. If Karachi's cash book includes Lahore's To-Pay, Karachi's manager is rewarded for Lahore's bookings and Lahore's manager is blamed for Karachi's costs. Worse, when cash is short at a station, nobody can say whether it was stolen or was simply never the station's money in the first place.</p>

<h2>How to run inter-station accounts</h2>

<ol>
  <li><strong>One cash book per station.</strong> Every rupee in or out is entered at the station where the cash physically is.</li>
  <li><strong>Tag every cross-station entry.</strong> To-Pay on another station's bilty, a balance on another station's challan: the entry names the other station.</li>
  <li><strong>Let the balance build automatically.</strong> Each tagged entry updates the account between the two stations — nobody should be adding it up by hand at month end.</li>
  <li><strong>Settle weekly, on a fixed day.</strong> The station that owes pays the other (a bank transfer, or cash sent with a trusted person), and the settlement is recorded in both cash books at once.</li>
  <li><strong>Review the balances every morning.</strong> A balance growing week after week is a station not settling, and that is a management conversation, not an accounting one.</li>
</ol>

<h2>What reports should you look at?</h2>

<ul>
  <li><strong>Station balances</strong> — for every pair of stations, the net amount one owes the other right now.</li>
  <li><strong>Station statement</strong> — every entry between two stations since the last settlement, so a disputed figure can be traced to the bilty or challan behind it.</li>
  <li><strong>Station profit</strong> — freight earned by each station's bookings minus its own costs, with cross-station money in the right place.</li>
</ul>

<h2>A common mistake: settling by adjusting cash</h2>

<p>When stations "settle" by quietly moving cash between themselves without recording it, the next reconciliation cannot tell a settlement from a loss. A settlement is a transaction in its own right: it is entered, with the amount and the date, and it brings the balance back towards zero.</p>

<h2>Doing it in software</h2>

<p><a href="/solutions/goods-transport">Irsaal for Goods Transport</a> keeps a cash book for every station and an account between every pair of stations: To-Pay collected for another station and driver balances paid on another station's challan are posted there on their own, and settlements are recorded against the balance, with a station balances report and statement behind every figure. Related: <a href="/blog/to-pay-freight-collection">collecting To-Pay freight</a> and <a href="/blog/loading-challan-kiraya-advance">the loading challan</a>.</p>

<h2>Frequently asked questions</h2>

<h3>What is an inter-station account in goods transport?</h3>
<p>It is a running balance between two stations of the same transport company, recording money one station collected or paid on the other's behalf, such as To-Pay freight or a driver's balance.</p>

<h3>How often should stations settle?</h3>
<p>Weekly on a fixed day works for most companies. Daily is better for very busy routes; monthly lets balances grow large enough to hide problems.</p>

<h3>Why not just pool all the cash at head office?</h3>
<p>You can, but each station still needs to know its own results. Inter-station accounts give each station a true cash book and profit figure even when the money ends up in one place.</p>

<h3>What if two stations disagree on the balance?</h3>
<p>Go to the station statement: every entry in the balance points to a bilty or a challan, so the disagreement becomes a question about one document rather than about a total.</p>]]></content:encoded>
    <category>Goods Transport</category>
  </item>
  <item>
    <title>A Delivery App Your Drivers Can Read: English and Urdu on the Round</title>
    <link>https://irsaalsystems.com/blog/urdu-rider-app-gulf-delivery-drivers</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/urdu-rider-app-gulf-delivery-drivers</guid>
    <pubDate>Sun, 27 Sep 2026 04:00:00 +0000</pubDate>
    <description>The office picks the software; the driver is the one who types into it, at a door, in a hurry. Why the language on the driver&#039;s screen decides whether the record is any good.</description>
    <content:encoded><![CDATA[<p><strong>A delivery record is only as good as what the driver types at the door, and a driver types more accurately in the language he reads fastest.</strong> The office chooses the software, but the office is not the one using it with a 5-gallon bottle on one shoulder. If the driver's screen is in a language he reads slowly, he will tap what looks right and move on.</p>

<h2>Where do wrong entries come from?</h2>
<p>Not from carelessness. They come from a screen that asks for "delivered" and "collected" in words the driver has to work out, three hundred times a day. The two numbers get swapped, or one is left at zero, and the customer's bottle balance is wrong from that stop onwards. Nobody notices until the customer disputes it.</p>

<h2>What does the driver actually need on screen?</h2>
<ul>
  <li><strong>The round, in order.</strong> Today's stops as a list, the next one at the top.</li>
  <li><strong>Three questions per stop.</strong> How many delivered, how many empties collected, how much paid.</li>
  <li><strong>It working with no signal.</strong> Basements, lifts and the edge of town. The stop is recorded on the phone and sent when the signal returns.</li>
  <li><strong>A receipt.</strong> Printed or shown, so the customer sees the same numbers the driver entered.</li>
  <li><strong>His own language.</strong> Chosen per driver, not per company.</li>
</ul>

<h2>Why per driver, not per company?</h2>
<p>Because one round has more than one kind of reader. A supervisor may prefer English; a driver may read Urdu far more easily. If the language is a company setting, somebody is always reading a second language at speed.</p>

<h2>Does the office need the same language?</h2>
<p>No. Reports, ledgers and invoices are read slowly, at a desk, and usually in English. What matters is that the driver's entry and the office's report are the same record seen in two languages — not two systems.</p>

<h2>Where Irsaal fits</h2>
<p>Irsaal's rider app runs in English or Urdu, switched by each rider on their own phone, and works offline. The office panel is in English. That is the whole list: there is no Arabic or Hindi interface, so a round whose drivers read only those is not one it will suit yet. It has been open to businesses in the <a href="/gulf">Gulf</a> since October 2026, where a great many delivery drivers read Urdu.</p>

<h2>Frequently asked questions</h2>

<h3>Is there a delivery driver app in Urdu?</h3>
<p>Yes. Irsaal's rider app runs in English or Urdu, chosen by each rider, and records deliveries, returns and payments offline.</p>

<h3>Is the Irsaal app available in Arabic?</h3>
<p>Not yet. The rider app is in English and Urdu and the office panel is in English.</p>

<h3>Can two drivers on the same account use different languages?</h3>
<p>Yes. The language is each rider's own setting, so one can work in English and another in Urdu on the same day.</p>]]></content:encoded>
    <category>Operations</category>
  </item>
  <item>
    <title>Short, Damaged or Missing: Stopping Cargo Loss Between Loading and Delivery</title>
    <link>https://irsaalsystems.com/blog/stop-cargo-loss-loading-receiving</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/stop-cargo-loss-loading-receiving</guid>
    <pubDate>Sun, 27 Sep 2026 04:00:00 +0000</pubDate>
    <description>Cargo goes missing in the gaps between counts. Count at booking, at loading, at unloading and at handover — and record every difference against a bilty and a vehicle.</description>
    <content:encoded><![CDATA[<p><strong>Cargo loss stops when every handover is a count against paper: packages counted onto the bilty at booking, onto the challan at loading, off the vehicle at receiving, and across the counter at delivery — with any difference recorded against the bilty, the vehicle and the driver at the moment it is found.</strong> A shortage found at the next count is a question about one trip. A shortage found a week later is a loss.</p>

<h2>Where does cargo actually go missing?</h2>

<table>
  <thead>
    <tr><th>Gap</th><th>What goes wrong</th><th>The control</th></tr>
  </thead>
  <tbody>
    <tr><td>Booking</td><td>Packages written as "goods" or miscounted</td><td>Count and describe every line: "5 cartons crockery", not "crockery"</td></tr>
    <tr><td>Godown, before loading</td><td>Consignments mixed up or left behind</td><td>Store by destination; load from the challan list, not from memory</td></tr>
    <tr><td>Loading</td><td>A carton loaded onto the wrong vehicle</td><td>Tick each bilty and its package count onto the challan</td></tr>
    <tr><td>On the road</td><td>Theft, breakage, water damage</td><td>Seal and tarp; driver signs for the count</td></tr>
    <tr><td>Receiving</td><td>Short or damaged goods accepted without a record</td><td>Unload bilty by bilty; record all there, short, damaged or missing</td></tr>
    <tr><td>Delivery</td><td>Goods handed to the wrong person</td><td>Hand over against bilty number and CNIC, with a signature</td></tr>
  </tbody>
</table>

<h2>Why receiving is the step that matters most</h2>

<p>Receiving is where a shortage gets a name on it. If the destination station unloads a vehicle and records, bilty by bilty, that bilty LHR-00412 arrived with 4 of 5 cartons, the shortage belongs to that trip, that vehicle and that driver — and it is known <em>before</em> the driver's balance is paid, which is the only moment you still hold something to deduct from. Receiving "by eye" and sorting it out when the receiver complains means the driver has been paid and gone.</p>

<h2>What to record for each problem</h2>

<ul>
  <li><strong>Short</strong> — how many packages arrived against how many were booked.</li>
  <li><strong>Damaged</strong> — which packages, what damage, and a photo while the vehicle is still there.</li>
  <li><strong>Missing</strong> — the whole consignment did not arrive; start the search from the loading challan.</li>
</ul>

<p>Tell the receiver straight away. Hearing about a damaged carton from you, the day it arrives, is a service; hearing about it from the counter clerk when they come to collect is a dispute.</p>

<h2>How should claims be handled?</h2>

<p>Settle the rule before anything is lost: what the company pays for (usually up to the declared value, if one was declared and the goods were properly packed), what it does not (leakage from bad packing, undeclared valuables), and how long a claim can be made. Print it on the bilty. Then every claim is decided against the bilty, the receiving record and the rule — not against how angry the customer is.</p>

<h2>Measure it</h2>

<p>Track shortages and damage per route and per driver each month. Losses are rarely random: one route with bad roads breaks more crockery, one vehicle arrives short more often than the rest. A monthly list turns "we lose a bit here and there" into two names and a route.</p>

<h2>Doing it in software</h2>

<p><a href="/solutions/goods-transport">Irsaal for Goods Transport</a> has the receiving station unload each vehicle bilty by bilty — all there, short, damaged or missing — before the driver's balance is cleared, and hands goods over at the delivery desk against the bilty and the receiver's CNIC. See also <a href="/blog/loading-challan-kiraya-advance">the loading challan and the driver's balance</a>.</p>

<h2>Frequently asked questions</h2>

<h3>How do transport companies reduce lost cargo?</h3>
<p>By counting packages at every handover — booking, loading, unloading and delivery — against the bilty and the loading challan, and recording any shortage against the vehicle and driver when it is found.</p>

<h3>When should a shortage be recorded?</h3>
<p>At unloading, before the driver's balance is paid. That is when the trip responsible is known and there is still money to hold back.</p>

<h3>Is the transporter responsible for damaged goods?</h3>
<p>That depends on the terms printed on the bilty and on whether the goods were properly packed and their value declared. Agree and print the terms before accepting goods.</p>

<h3>What is declared value on a bilty?</h3>
<p>It is the value the sender states for the goods at booking. It is usually the basis, and the limit, of any claim for loss or damage.</p>]]></content:encoded>
    <category>Goods Transport</category>
  </item>
  <item>
    <title>Running a 5-Gallon Water Delivery Business in the Gulf: The Operations Checklist</title>
    <link>https://irsaalsystems.com/blog/5-gallon-water-delivery-business-operations-checklist</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/5-gallon-water-delivery-business-operations-checklist</guid>
    <pubDate>Sat, 26 Sep 2026 04:00:00 +0000</pubDate>
    <description>Licences and water quality are for the authorities to approve. This is the other half: the seven records a 5-gallon delivery business needs from its first week, and what goes wrong without each.</description>
    <content:encoded><![CDATA[<p><strong>A 5-gallon delivery business needs seven records from its first week: customers, bottles out, deposits held, money paid ahead, routes, each driver's cash, and the price each customer was promised.</strong> Licensing, premises and water quality are decided by the authorities where you trade, and they differ from one emirate or country to the next — ask them, not a blog. This is the half nobody inspects: the bookkeeping of a round.</p>

<h2>1. A customer list that is more than names</h2>
<p>For each customer: where the door is, which floor, who to ask for, how they pay and how often they take water. "Villa 14, behind the mosque" is a record only the driver who wrote it can use.</p>

<h2>2. Bottles out, per customer</h2>
<p>Your bottles are the largest thing you own that is not in your building. Count them per customer from the first delivery. The opening count is the one worth doing slowly — every later figure is measured against it. See <a href="/blog/how-to-track-returnable-water-bottles">tracking returnable bottles</a>.</p>

<h2>3. Deposits, held against those bottles</h2>
<p>Take the deposit when the bottle goes in, and keep it against the number of bottles. A deposit you cannot match to a bottle count is a number in an account, not protection.</p>

<h2>4. Money paid ahead</h2>
<p>Coupon books and prepayments are money you owe water for. Keep it per customer. See <a href="/blog/5-gallon-bottle-deposits-and-coupons">deposits and coupon books</a>.</p>

<h2>5. Routes in the order they are driven</h2>
<p>A route is a list of customers in delivery order. Written down, it survives the driver who knows it leaving. Kept with what each stop took, it tells you what to load. See <a href="/blog/delivery-route-planning-water-suppliers">route planning</a>.</p>

<h2>6. Each driver's cash, closed daily</h2>
<p>What the round collected, what was spent, what was handed in, who approved it. See <a href="/blog/rider-cash-reconciliation-delivery-business">reconciling driver cash</a>.</p>

<h2>7. The price each customer was promised</h2>
<p>A company on a contract rate, a tower on a coupon price, an old customer on last year's price. If the price lives in somebody's head, every invoice is a chance to get it wrong.</p>

<h2>What goes wrong without each</h2>
<table>
  <thead><tr><th>Missing record</th><th>What you find out, and when</th></tr></thead>
  <tbody>
    <tr><td>Bottles per customer</td><td>At stock-take: fewer bottles than you bought, and no names</td></tr>
    <tr><td>Deposits against bottles</td><td>When a customer leaves holding more than they paid for</td></tr>
    <tr><td>Money paid ahead</td><td>When a customer says they had coupons left</td></tr>
    <tr><td>Driver cash</td><td>At month end, as a difference nobody can explain</td></tr>
    <tr><td>Promised prices</td><td>When a contract customer disputes an invoice</td></tr>
  </tbody>
</table>

<h2>Paper, a spreadsheet or software?</h2>
<p>Paper works for one route. A spreadsheet works for totals, and fails at anything recorded at a door. Software earns its cost at about the point you add a second driver — when you are no longer on the truck yourself.</p>

<h2>Where Irsaal fits</h2>
<p><a href="/gulf">Irsaal</a> keeps all seven: customers with a pinned door and a photo, a bottle balance and deposit per customer, prepayments as an advance, routes, a daily close of each rider's cash, and a price per customer. It has been open to businesses in the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain and Oman since October 2026, in their own currency. The panel is in English and the rider app in English or Urdu; there is no Arabic interface, and it does not replace your accounting or tax software.</p>

<h2>Frequently asked questions</h2>

<h3>What records does a 5-gallon water delivery business need?</h3>
<p>Customers, bottles out per customer, deposits held, money paid in advance, routes, each driver's daily cash, and the price agreed with each customer.</p>

<h3>When should a water delivery business move from paper to software?</h3>
<p>Usually when a second driver joins. From then on the owner is not at every door, and what happened there has to be recorded by somebody else.</p>

<h3>Does this cover licences and water quality rules?</h3>
<p>No. Those are set by the authorities where you trade and vary by country and emirate. This checklist covers the day-to-day records of the round.</p>]]></content:encoded>
    <category>Guides</category>
  </item>
  <item>
    <title>Bilty Tracking by SMS and WhatsApp: What Your Customers Expect Now</title>
    <link>https://irsaalsystems.com/blog/bilty-tracking-sms-whatsapp</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/bilty-tracking-sms-whatsapp</guid>
    <pubDate>Sat, 26 Sep 2026 04:00:00 +0000</pubDate>
    <description>Senders and receivers now expect a message when goods are booked, dispatched and arrive, and a page to check the bilty. Here is how to give them that without flooding your phone lines.</description>
    <content:encoded><![CDATA[<p><strong>Customers of a goods transport company now expect two things: a message at each step — booked, dispatched, arrived, delivered — and a page where they can type the bilty number and see where their goods are.</strong> Give them both and the phone calls asking "has my maal arrived?" mostly stop, which on a busy counter is worth hours a day.</p>

<h2>Which messages should you send?</h2>

<table>
  <thead>
    <tr><th>Step</th><th>To</th><th>What it should say</th></tr>
  </thead>
  <tbody>
    <tr><td>Booked</td><td>Sender and receiver</td><td>Bilty number, destination, number of packages, Paid or To-Pay, tracking link</td></tr>
    <tr><td>Dispatched</td><td>Receiver</td><td>Goods on the way, expected arrival</td></tr>
    <tr><td>Arrived</td><td>Receiver</td><td>Ready to collect at the station, To-Pay amount if any, what to bring (bilty number and CNIC)</td></tr>
    <tr><td>Delivered</td><td>Sender</td><td>Handed over, and when</td></tr>
  </tbody>
</table>

<p>The arrival message does the most work: it is what brings the receiver in, and it is what shortens the time goods sit in your godown.</p>

<h2>SMS or WhatsApp?</h2>

<p>Both have a place. SMS reaches every phone, including basic handsets, and does not depend on the receiver having saved your number. WhatsApp is cheaper per message and familiar, but messages to a number that has never talked to you need an approved business template. Many transporters send SMS as the default and use WhatsApp where the customer prefers it.</p>

<p>In Pakistan, bulk SMS to customers goes through a provider, and some providers accept only wording approved by the PTA as a template. Keep your messages short, factual and the same every time — "Bilty LHR-00412: 5 packages arrived at Karachi station. To-Pay Rs. 4,200. Bring bilty no. and CNIC." — so they can be approved once and used forever. Use two providers if you can, so a message still goes out when one is down.</p>

<h2>What should the tracking page show — and hide?</h2>

<p>Show the status and every step with its date and station: booked at Lahore, dispatched on vehicle LES-1234, arrived at Karachi, delivered. Show the package count and whether To-Pay is due.</p>

<p>Hide, or mask, the personal details: anyone who knows or guesses a bilty number can open the page, so names and phone numbers should appear only partly ("Ka*** Tr***", "0321-****222"). A tracking page that shows full names and numbers publishes your customers' details to the internet.</p>

<h2>Does tracking really cut phone calls?</h2>

<p>It cuts the calls that are only asking where the goods are, which on most counters are the majority. The calls that remain — a damaged carton, a changed delivery address — are the ones that need a person. Put the tracking link in every message and print a QR code on the sender's copy of the bilty so nobody has to type anything.</p>

<h2>Doing it in software</h2>

<p><a href="/solutions/goods-transport">Irsaal for Goods Transport</a> sends SMS or WhatsApp alerts to senders and receivers at booking, departure, arrival and delivery — through a main and a backup SMS provider, with the wording laid out ready to submit for approval — and gives every company a tracking page at its own address, with names and phone numbers masked, plus a QR code on every bilty. Read more on <a href="/blog/what-is-a-bilty">what a bilty should show</a>.</p>

<h2>Frequently asked questions</h2>

<h3>How can customers track a bilty online?</h3>
<p>By entering the bilty number on the transporter's tracking page, or scanning the QR code printed on their copy of the bilty, which shows each step with its date and station.</p>

<h3>Should a transporter use SMS or WhatsApp for alerts?</h3>
<p>SMS reaches every phone and is the safest default; WhatsApp is cheaper and familiar but needs approved templates for business messages. Many transporters use both.</p>

<h3>Is it safe to show customer details on a tracking page?</h3>
<p>Only partly. A tracking page should mask names and phone numbers, because anyone with a bilty number can open it.</p>

<h3>Which message matters most?</h3>
<p>The arrival message to the receiver, with any To-Pay amount and what to bring. It brings receivers in quickly and keeps goods from sitting in the godown.</p>]]></content:encoded>
    <category>Goods Transport</category>
  </item>
  <item>
    <title>Planning for Summer Demand in a Gulf Water Delivery Round</title>
    <link>https://irsaalsystems.com/blog/summer-demand-planning-water-delivery-gulf</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/summer-demand-planning-water-delivery-gulf</guid>
    <pubDate>Fri, 25 Sep 2026 04:00:00 +0000</pubDate>
    <description>Summer does not arrive as a surprise, but it is planned for as if it did. How to use last year&#039;s own round to decide this year&#039;s bottles, loads and drivers.</description>
    <content:encoded><![CDATA[<p><strong>Plan summer from your own round: what each route took in the same weeks last year, how many bottles were out at the peak, and how many stops a driver managed before the heat. Those three numbers decide the bottles to buy, the loads to send and the drivers to hire.</strong> A supplier without them plans from a feeling, and a feeling is usually last week.</p>

<h2>Why does summer break a round?</h2>
<p>Three things move at once. Each customer takes more water. Each takes it sooner, so the gap between visits shrinks. And each stop is slower, because nobody works at the same pace in that heat. A round that fitted in a day in February does not in July — and the bottles are with customers for less time but in greater number.</p>

<h2>What should you look up before the season?</h2>
<table>
  <thead><tr><th>Number</th><th>Where it comes from</th><th>What it decides</th></tr></thead>
  <tbody>
    <tr><td>Bottles delivered per route, per week, last summer</td><td>Your delivery record</td><td>How many to fill and load</td></tr>
    <tr><td>Bottles out with customers at the peak</td><td>Your bottle balance per customer</td><td>How many bottles you need to own</td></tr>
    <tr><td>Stops per driver per day in the hottest weeks</td><td>Your round history</td><td>How many drivers and trucks</td></tr>
    <tr><td>Customers who ran out between visits</td><td>Extra orders and calls</td><td>Whose schedule to shorten</td></tr>
  </tbody>
</table>

<h2>How many more bottles do you need?</h2>
<p>Not "more". Look at the most bottles you had out with customers at once last summer, add what was in the store and on the trucks that week, and compare it with what you own now. If customers have grown since, scale it. That is the number to buy — before the season, when you can still get them.</p>

<h2>Change the hours, not just the load</h2>
<p>Start earlier and stop for the afternoon. A split day with the heaviest routes first keeps the stops-per-driver figure from collapsing. Decide it before the first driver decides it for you.</p>

<h2>Shorten the gap for the customers who ran out</h2>
<p>The customers who called for extra water last July will call again. Move them to a shorter interval for the season — two visits a week instead of one — rather than sending a truck out for one stop.</p>

<h2>Watch the empties harder</h2>
<p>More bottles go out in summer, so more can fail to come back. Collected has to be recorded at every stop, exactly when drivers are most rushed. See <a href="/blog/reduce-bottle-loss-water-delivery">reducing bottle loss</a>.</p>

<h2>Where Irsaal fits</h2>
<p>These numbers only exist if the round was recorded. <a href="/gulf">Irsaal</a> records delivered and collected at every stop, keeps a bottle balance per customer, and reports deliveries by route and by rider, so last summer is there to read. Customers on a repeating schedule can have their days changed for the season. It has been open to businesses in the Gulf since October 2026 — which means a supplier starting now will have this summer's figures for next year, not last year's.</p>

<h2>Frequently asked questions</h2>

<h3>How do I estimate summer demand for a water delivery business?</h3>
<p>From your own records: bottles delivered per route in the same weeks last year, adjusted for the customers you have gained or lost since.</p>

<h3>How many 5-gallon bottles should a supplier own?</h3>
<p>Enough to cover the most that were out with customers at once in the peak week, plus those in the store and on the trucks. That figure comes from a bottle balance kept per customer.</p>

<h3>Should delivery hours change in summer?</h3>
<p>Usually yes: an early start and an afternoon break keep the number of stops per driver up when the heat would otherwise cut it.</p>]]></content:encoded>
    <category>Operations</category>
  </item>
  <item>
    <title>How to Choose Goods Transport Software in Pakistan: A Buyer&#039;s Checklist</title>
    <link>https://irsaalsystems.com/blog/choose-goods-transport-software-pakistan</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/choose-goods-transport-software-pakistan</guid>
    <pubDate>Fri, 25 Sep 2026 04:00:00 +0000</pubDate>
    <description>Twelve questions to ask any goods transport or bilty software before you buy — from To-Pay and inter-station accounts to SMS rules, stations, cost and leaving.</description>
    <content:encoded><![CDATA[<p><strong>Choose goods transport software by how well it follows a consignment <em>after</em> the bilty is printed: onto a vehicle, off it, across the counter with To-Pay collected, and into the right station's cash.</strong> Almost every product can print a bilty. Far fewer can tell you, a month later, which station is holding which freight and what each driver is still owed — and that is what you are buying.</p>

<p>Here are the questions to ask, in order of how much money they protect.</p>

<h2>1. Does it collect To-Pay before the goods are handed over?</h2>
<p>The delivery counter should refuse to record a handover while To-Pay is outstanding, unless that receiver is on agreed credit. Ask to see it. See <a href="/blog/to-pay-freight-collection">why To-Pay is where money goes missing</a>.</p>

<h2>2. Does it keep accounts between stations?</h2>
<p>To-Pay collected at Karachi for a Lahore bilty, a driver's balance paid in Karachi on a Lahore challan: the software should post both into an account between the two stations and let them settle it. Without this, every multi-station report is wrong. See <a href="/blog/inter-station-accounts-goods-transport">inter-station accounts</a>.</p>

<h2>3. Does the loading challan carry the driver's money?</h2>
<p>Kiraya agreed, advance at loading, extra advances on the road, balance at unloading — all against one challan, each paid from the cash of the station that paid it.</p>

<h2>4. Does receiving work bilty by bilty?</h2>
<p>You want all there, short, damaged or missing recorded per bilty at unloading, before the driver's balance is paid.</p>

<h2>5. Does every station have its own cash book?</h2>
<p>And do staff see only their own station, while the owner sees all of them together?</p>

<h2>6. Can customers track a bilty — without seeing other people's details?</h2>
<p>A public tracking page, a QR code on the bilty, and masked names and numbers.</p>

<h2>7. Does it send SMS and WhatsApp alerts that will actually be delivered?</h2>
<p>Ask which SMS providers it supports, whether it can fall back to a second provider, and whether its message wording is ready for PTA template approval.</p>

<h2>8. Is it priced by what you actually grow — stations?</h2>
<p>A transport company grows by opening stations. Per-user pricing punishes you for giving the counter clerk a login; per-bilty pricing punishes a good month.</p>

<h2>9. Does it run in a browser, at every station, without installation?</h2>
<p>Cloud software means a new station is a laptop and an internet connection, not an installation visit, and every station sees the same records at once. Ask what happens when the internet drops.</p>

<h2>10. Can staff work in Urdu?</h2>
<p>Counter staff should be able to work in the language they read fastest.</p>

<h2>11. What does a full day's report look like?</h2>
<p>Ask for the evening view: bookings and freight by station, To-Pay outstanding, vehicles on the road with drivers' balances, cash by station, balances between stations, shortages this week.</p>

<h2>12. How do you leave?</h2>
<p>Your bilties, customers and accounts are yours. Ask how you export them, in what format, and whether leaving costs anything.</p>

<h2>A quick comparison of the usual options</h2>

<table>
  <thead>
    <tr><th>Option</th><th>Good for</th><th>Where it falls short</th></tr>
  </thead>
  <tbody>
    <tr><td>Registers and carbon bilty books</td><td>One or two stations, few vehicles</td><td>No live view of goods, To-Pay or station balances</td></tr>
    <tr><td>Spreadsheets</td><td>An owner who wants totals</td><td>Every station edits its own copy; nothing enforces rules</td></tr>
    <tr><td>General accounting software</td><td>Books of account and tax</td><td>Knows invoices, not bilties, challans or stations</td></tr>
    <tr><td>Courier software</td><td>Parcel delivery to doors</td><td>Built for individual parcels, not consignments between your own stations</td></tr>
    <tr><td>Purpose-built bilty software</td><td>Multi-station goods transport</td><td>Choose carefully: check the twelve questions above</td></tr>
  </tbody>
</table>

<h2>Where Irsaal fits — and where it does not</h2>

<p><a href="/solutions/goods-transport">Irsaal for Goods Transport</a> is built for a Pakistani goods transport company that books at its own stations and carries on hired vehicles: bilties with station codes and QR tracking, loading challans with kiraya and advance, receiving bilty by bilty, To-Pay at the delivery desk, a cash book per station, inter-station accounts, SMS and WhatsApp alerts, a website with tracking and booking requests, and plans priced by the number of stations. It runs in a browser, in English or Urdu.</p>

<p>It is the wrong choice for last-mile parcel courier work, for vehicle GPS tracking, or for a company that needs software installed on its own server. See <a href="/pricing?for=transport">pricing</a> or <a href="/get-started?for=transport">start a free trial</a>.</p>

<h2>Frequently asked questions</h2>

<h3>What is the best goods transport software in Pakistan?</h3>
<p>The best one is the one that handles your whole day: bilties, loading challans, receiving, To-Pay at the delivery desk, a cash book per station and accounts between stations. Irsaal for Goods Transport is built for exactly that, for Pakistani transporters, and can be tried free.</p>

<h3>How much does goods transport software cost?</h3>
<p>Prices vary by vendor. Look for pricing by number of stations rather than per user or per bilty; Irsaal publishes its prices on its pricing page, with plans starting from two stations.</p>

<h3>Is cloud software safe for a transport company?</h3>
<p>Cloud software keeps records off the station computers, so a stolen laptop or a failed hard disk loses nothing. Ask how each company's data is kept separate from others'.</p>

<h3>Can I try bilty software before buying?</h3>
<p>Many vendors offer a trial. Irsaal's is 14 days, with no card required, and starts with your first station already set up from your city.</p>]]></content:encoded>
    <category>Goods Transport</category>
  </item>
  <item>
    <title>From Registers to Software: Moving a Goods Transport Company Over in 30 Days</title>
    <link>https://irsaalsystems.com/blog/goods-transport-registers-to-software</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/goods-transport-registers-to-software</guid>
    <pubDate>Thu, 24 Sep 2026 04:00:00 +0000</pubDate>
    <description>A four-week plan for moving a multi-station goods transport company from carbon bilty books and registers to software — without stopping the counter for a day.</description>
    <content:encoded><![CDATA[<p><strong>Move one station first, for one week, with both the register and the software running side by side; then add a station a week, and switch the registers off only when the software's evening figures match the registers for a full week.</strong> Companies that try to move every station on the same morning usually end up back on paper by Thursday, with two half-kept records instead of one.</p>

<h2>Week 1 — Set up and one station</h2>

<ul>
  <li><strong>Stations and codes.</strong> Create every station with a short code (LHR, KHI, FSD) — it becomes the prefix of every bilty number.</li>
  <li><strong>Freight rates.</strong> Enter the rate card for your main routes: per kg, per package and a minimum. Rates can be added as you go; the busiest ten routes cover most bookings.</li>
  <li><strong>Staff logins.</strong> Each clerk gets their own login tied to their station. Shared logins make every mistake nobody's.</li>
  <li><strong>Start booking at one station.</strong> Choose the busiest booking station, and book every new bilty in the software while the register carries on as usual.</li>
</ul>

<h2>Week 2 — Loading, receiving and the second station</h2>

<ul>
  <li>Write loading challans in the software for vehicles leaving the first station, with kiraya and advance.</li>
  <li>Bring the main destination station on: it receives those vehicles bilty by bilty and hands goods over at the delivery desk, collecting To-Pay.</li>
  <li>Compare each evening: bilties booked, freight, cash — software against register. Every difference is either a training point or a rule to settle.</li>
</ul>

<h2>Week 3 — The rest of the stations, and the money between them</h2>

<ul>
  <li>Add the remaining stations, one or two at a time.</li>
  <li>Enter each station's <strong>opening cash</strong> and the <strong>opening balances between stations</strong> — what each owes the others on the day you start. Get both station managers to agree the figure before it goes in.</li>
  <li>Old bilties still in the godown: enter them as bookings dated the day they were booked, so arrival and To-Pay collection happen in the software.</li>
</ul>

<h2>Week 4 — Alerts, the website and switching the registers off</h2>

<ul>
  <li>Switch on SMS or WhatsApp alerts once every station is booking in the software — a customer who gets alerts for some bilties and not others calls more, not less.</li>
  <li>Publish the tracking page and put the link and QR code on every bilty.</li>
  <li>When the evening figures have matched the registers for a full week, stop writing the registers. Keep the old books; do not keep writing them.</li>
</ul>

<h2>What usually goes wrong</h2>

<table>
  <thead>
    <tr><th>Problem</th><th>Cause</th><th>Fix</th></tr>
  </thead>
  <tbody>
    <tr><td>Clerks go back to paper when it is busy</td><td>Booking takes longer at first</td><td>Rates and regular customers entered in advance; one person to help at peak hours for the first week</td></tr>
    <tr><td>Station balances never agree</td><td>Opening balances guessed</td><td>Agree them between managers before entering them</td></tr>
    <tr><td>To-Pay "missing" in the first weeks</td><td>Old bilties not entered</td><td>Enter everything still in the godown on the day the station starts</td></tr>
    <tr><td>The owner still phones stations for figures</td><td>Nobody looks at the reports</td><td>A fixed evening routine: the same six numbers every day</td></tr>
  </tbody>
</table>

<h2>Doing it with Irsaal</h2>

<p><a href="/solutions/goods-transport">Irsaal for Goods Transport</a> is set up for exactly this: your trial starts with your first station already made from your city, stations and staff are added as you go, and every station works in a browser from its first day. The trial is 14 days and takes no card — enough time for the first two weeks of this plan. <a href="/get-started?for=transport">Start here</a>, and read <a href="/blog/bilty-software-goods-transport-company">how a transport company runs on bilty software</a> for the day you are moving to.</p>

<h2>Frequently asked questions</h2>

<h3>How long does it take to move a transport company to software?</h3>
<p>About four weeks for a company with several stations, moving one station at a time and running the registers alongside until the figures match for a week.</p>

<h3>Should every station start on the same day?</h3>
<p>No. Start with the busiest booking station and its main destination, then add stations one or two at a time.</p>

<h3>What about bilties already in the godown?</h3>
<p>Enter them on the day each station starts, dated when they were booked, so their arrival and To-Pay collection are recorded in the software.</p>

<h3>Do we need new computers?</h3>
<p>Browser-based software runs on the computers and phones you already have; each station needs an internet connection and, ideally, a printer for bilties.</p>]]></content:encoded>
    <category>Goods Transport</category>
  </item>
  <item>
    <title>How to Choose Water Delivery Software in Pakistan: A Buyer&#039;s Checklist</title>
    <link>https://irsaalsystems.com/blog/choose-water-delivery-software-pakistan</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/choose-water-delivery-software-pakistan</guid>
    <pubDate>Wed, 23 Sep 2026 04:00:00 +0000</pubDate>
    <description>Ten questions to ask any water delivery software before you pay for it — starting with the one most products get wrong: whether it can tell you where every 19 litre bottle is.</description>
    <content:encoded><![CDATA[<p><strong>Choose water delivery software by whether it can prove where every returnable bottle is — per customer, today — and whether it settles each rider's cash and bottles at the end of every round.</strong> Invoicing, routes and reports come with almost every product. Those two do not, and they are where a water business actually loses money.</p>

<h2>1. Does it track bottles as a balance per customer?</h2>
<p>Delivered and collected recorded separately at every stop, and a live count of how many bottles each customer holds. Ask the vendor to show you the twenty customers holding the most bottles. See <a href="/blog/how-to-track-returnable-water-bottles">how to track returnable bottles</a>.</p>

<h2>2. Does it tie the security deposit to that count?</h2>
<p>A deposit is only useful compared against the bottles held. The software should show who holds more bottles than their deposit covers — and tell apart bottles covered by a deposit, bottles the customer owns, and bottles lent on trust.</p>

<h2>3. Does the rider app work offline?</h2>
<p>Rounds go through basements, markets and outskirts with weak signal. The app must record the whole round offline and sync later — ask what happens to a stop recorded with no signal.</p>

<h2>4. Does each rider settle at the end of the day?</h2>
<p>Cash collected, bottles out and back, expenses — reconciled per rider every evening, approved by the office. Monthly reconciliation finds problems too late to explain them.</p>

<h2>5. Can it bill monthly customers automatically — at different rates?</h2>
<p>Homes, offices and shops rarely pay the same rate. Customer-specific prices and a way to bill offices weekly or monthly are basic requirements, not extras.</p>

<h2>6. How does it help you recover overdue balances?</h2>
<p>A list of who owes what, how old it is, and a message you can send in one tap. See <a href="/blog/recovery-collecting-overdue-balances-delivery">collecting overdue balances</a>.</p>

<h2>7. Can riders use it in Urdu?</h2>
<p>A rider who reads Urdu faster makes fewer mistakes in Urdu.</p>

<h2>8. Can customers order online?</h2>
<p>An online store where customers place orders, which land straight in the office's order list, removes a share of the phone calls.</p>

<h2>9. Can it prove a delivery happened?</h2>
<p>A delivery marked at the customer's pinned location, with a record the customer can open, ends "the rider never came" arguments.</p>

<h2>10. What does it cost, and how do you leave?</h2>
<p>Monthly pricing in PKR, a free trial, and a clear way to export your customers and balances if you ever go.</p>

<h2>How the usual options compare</h2>
<table>
  <thead><tr><th>Option</th><th>Good for</th><th>Falls short on</th></tr></thead>
  <tbody>
    <tr><td>Register and notebook</td><td>One route, one rider</td><td>Bottle counts per customer, rider cash</td></tr>
    <tr><td>Spreadsheet</td><td>Monthly totals</td><td>Anything recorded at the door</td></tr>
    <tr><td>Accounting or POS software</td><td>Invoices and tax</td><td>Returnable bottles, routes, riders</td></tr>
    <tr><td>Purpose-built water delivery software</td><td>Multi-route suppliers</td><td>Check the ten questions above</td></tr>
  </tbody>
</table>

<h2>Where Irsaal fits</h2>
<p><a href="/solutions/water-delivery">Irsaal for Water Delivery</a> is built for Pakistani water suppliers: bottles tracked per customer and split into deposit-covered, customer-owned and lent-on-trust; an offline rider app in English or Urdu with Bluetooth receipts; per-rider end-of-day settlement; an invoice at every delivery, weekly or monthly payment plans and recovery; an online store; and deliveries recorded at the customer's pin. It is not the right choice for parcel couriers or restaurant delivery. See <a href="/pricing?for=water">pricing</a> — the trial is 14 days and takes no card.</p>

<h2>Frequently asked questions</h2>

<h3>What is the best water delivery software in Pakistan?</h3>
<p>The one that tracks every returnable bottle per customer, ties deposits to that count, works offline for riders and settles each rider's cash daily. Irsaal for Water Delivery is built around exactly those needs for Pakistani suppliers and can be tried free for 14 days.</p>

<h3>Is there a water delivery app for riders that works offline?</h3>
<p>Yes. Irsaal's rider app records deliveries, returns, payments and new customers offline and syncs when signal returns, in English or Urdu.</p>

<h3>How much does water delivery software cost in Pakistan?</h3>
<p>It varies by vendor and size of business. Irsaal charges monthly in PKR, publishes its prices on its pricing page, and offers a 14-day free trial with no card.</p>

<h3>Can water delivery software track 19 litre bottles?</h3>
<p>Purpose-built software can: it records bottles delivered and collected at every stop and keeps a running balance per customer, with the deposit held against it.</p>]]></content:encoded>
    <category>Guides</category>
  </item>
  <item>
    <title>LPG Cylinder Distribution Software: What a Gas Agency Actually Needs</title>
    <link>https://irsaalsystems.com/blog/lpg-cylinder-distribution-software-guide</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/lpg-cylinder-distribution-software-guide</guid>
    <pubDate>Tue, 22 Sep 2026 04:00:00 +0000</pubDate>
    <description>An LPG round is an exchange business with a deposit on every cylinder. Here is what software for a gas agency or LPG distributor has to get right — and how to check it before you buy.</description>
    <content:encoded><![CDATA[<p><strong>LPG distribution software has to treat a refill as an exchange, not a sale: a full cylinder goes out, an empty one comes back, and a deposit is held against every cylinder a customer keeps.</strong> Software built for shops sells cylinders as products and loses track of them the first week. That is the test to apply before anything else.</p>

<h2>Why is LPG different from other deliveries?</h2>
<p>Three things, all at once. Cylinders are valuable — a deposit of several thousand rupees each — and they come back. They come in sizes (11.8 kg domestic and 45.4 kg commercial are the common ones in Pakistan), each with its own refill price and deposit. And stock is two numbers: full and empty. A gas agency that cannot say how many full cylinders it has, and how many empties are out with customers, is guessing its reorder.</p>

<h2>What to check before you buy</h2>
<table>
  <thead><tr><th>Need</th><th>What to ask to see</th></tr></thead>
  <tbody>
    <tr><td>Rates by size</td><td>A household on the 11.8 kg rate and a restaurant on the 45.4 kg rate, each billed and charged a deposit at their own price</td></tr>
    <tr><td>Full and empty stock</td><td>Stock split into full and empty — in the warehouse, at the plant, with customers and with riders — updated by every delivery and return</td></tr>
    <tr><td>Refill as an exchange</td><td>A refill that sends a full cylinder and brings an empty back in one step</td></tr>
    <tr><td>Deposits</td><td>Customers whose cylinders held exceed what their deposit covers</td></tr>
    <tr><td>Rider settlement</td><td>Each rider's cash and cylinders reconciled at the end of the day</td></tr>
    <tr><td>Billing and recovery</td><td>Credit for restaurants and shops, settled weekly or monthly, and a clear list of who owes what</td></tr>
    <tr><td>Offline rider app</td><td>A round recorded with no signal, synced later</td></tr>
  </tbody>
</table>

<h2>Restaurants and commercial customers</h2>
<p>Commercial customers change the shape of the business: larger cylinders, several at once, weekly swaps and monthly credit. Software should let those customers carry their own price, their own cylinder balance and credit settled weekly or monthly, while household customers pay per refill at the door.</p>

<h2>Where Irsaal fits</h2>
<p><a href="/solutions/lpg-cylinder-delivery">Irsaal for LPG Cylinder Delivery</a> is built for Pakistani gas agencies and distributors: full and empty cylinders counted wherever they are, a refill and deposit rate for each cylinder size through rate cards, refills handled as an exchange, deposits held against every cylinder a customer keeps, an offline rider app with Bluetooth receipts, per-rider settlement, an invoice at every delivery with weekly or monthly payment plans, and recovery. Each customer has one cylinder balance, billed at their own rate — a customer who takes both domestic and commercial cylinders is simplest kept as two accounts. See <a href="/pricing?for=lpg">pricing</a>; the trial is 14 days with no card.</p>

<h2>Frequently asked questions</h2>

<h3>Is there software for LPG cylinder delivery in Pakistan?</h3>
<p>Yes. Irsaal for LPG Cylinder Delivery handles customers, routes, riders, full and empty cylinder tracking, refill exchange, security deposits, rates per cylinder size, invoicing and recovery for Pakistani gas agencies.</p>

<h3>How do gas agencies track cylinders?</h3>
<p>By recording every cylinder delivered and every empty collected per customer, keeping full and empty stock separately, and holding a deposit against each cylinder a customer keeps.</p>

<h3>Can LPG software handle commercial customers on credit?</h3>
<p>Good LPG software gives commercial customers their own prices, cylinder balances and credit settled weekly or monthly, alongside household customers who pay per refill.</p>

<h3>Does an LPG rider app need to work offline?</h3>
<p>It should. Riders record exchanges and payments at the door; an app that loses them without signal loses cylinders and cash.</p>]]></content:encoded>
    <category>Guides</category>
  </item>
  <item>
    <title>Milk Shop and Dairy Software in Pakistan: A Practical Buyer&#039;s Guide</title>
    <link>https://irsaalsystems.com/blog/milk-shop-dairy-software-guide</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/milk-shop-dairy-software-guide</guid>
    <pubDate>Mon, 21 Sep 2026 04:00:00 +0000</pubDate>
    <description>A milk shop runs on a daily cycle: milk in from suppliers, subscribers served, riders settled in the evening, the counter selling the rest. Here is what dairy software has to handle.</description>
    <content:encoded><![CDATA[<p><strong>Dairy software has to run the milk shop's day as one cycle: milk in from suppliers in the morning, subscribers served first, riders issued milk and settled in the evening, and whatever is left sold over the counter — with every litre accounted for.</strong> Milk is measured, not counted, and nothing comes back empty, so software built for bottle rounds or shops misses most of what matters.</p>

<h2>The five parts of a milk shop's day</h2>
<table>
  <thead><tr><th>Part</th><th>What the software must do</th></tr></thead>
  <tbody>
    <tr><td>Supplier intake</td><td>Record litres (and mann) from each supplier, priced by fat and litre, and post it to that supplier's ledger</td></tr>
    <tr><td>Available milk</td><td>Show total milk minus what subscribers need today, so local sale never takes a subscriber's share</td></tr>
    <tr><td>Dispatch</td><td>Issue each rider the litres for their route, billing monthly subscribers automatically</td></tr>
    <tr><td>Evening settlement</td><td>Reconcile litres delivered and returned, cash from daily payers and payments from monthly customers — approved by the office</td></tr>
    <tr><td>Counter</td><td>Sell milk by the litre or millilitre, yogurt by the gram, eggs by the piece, with a receipt</td></tr>
  </tbody>
</table>

<h2>Subscribers are not all the same</h2>
<p>Some take milk every day, some on chosen weekdays, some on alternate days; some pay monthly, some pay cash daily; and every family goes away sometimes. Software should handle each schedule, and a "no delivery today" that removes the stop, the litres and the bill in one step.</p>

<h2>Production, wastage and your own milk</h2>
<p>Yogurt, butter and lassi use milk; spoiled milk is written off; milk from your own animals has a cost even if no supplier bills it. Good dairy software records production runs and wastage and, if you want, a cost for your own milk — so profit is not overstated.</p>

<h2>Where Irsaal fits</h2>
<p><a href="/solutions/milk-delivery">Irsaal for Milk Shops &amp; Dairies</a> runs this whole cycle: supplier intake by litre and fat, daily subscribers on any schedule, morning dispatch that bills monthly subscribers, evening rider settlement approved by the office, a counter POS with receipts straight to the printer, production and wastage, and reports. See <a href="/pricing?for=milk">pricing</a>; the trial is 14 days and takes no card.</p>

<h2>Frequently asked questions</h2>

<h3>Is there software for a milk shop in Pakistan?</h3>
<p>Yes. Irsaal for Milk Shops &amp; Dairies handles supplier intake by fat and litre, daily subscribers, rider dispatch and evening settlement, a counter POS, production and wastage.</p>

<h3>Can dairy software bill monthly milk subscribers automatically?</h3>
<p>Yes — in Irsaal, issuing milk to a rider bills every monthly subscriber on that route at their daily quantity and rate, while daily payers pay cash at the door.</p>

<h3>How is supplier milk priced in dairy software?</h3>
<p>By litre and fat: each delivery is recorded with its quantity and fat reading, priced at the agreed rate, and posted to the supplier's ledger.</p>

<h3>Can the software handle a milk rider's evening settlement?</h3>
<p>Yes. The rider reports litres delivered and returned, cash collected and expenses; nothing touches the accounts until the office approves the settlement.</p>]]></content:encoded>
    <category>Guides</category>
  </item>
  <item>
    <title>How to Track Returnable Water Bottles (Without Losing Count)</title>
    <link>https://irsaalsystems.com/blog/how-to-track-returnable-water-bottles</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/how-to-track-returnable-water-bottles</guid>
    <pubDate>Mon, 24 Aug 2026 19:22:12 +0000</pubDate>
    <description>A returnable bottle is an asset on loan, not a product sold. Here is the system that keeps the count honest — per customer, every day, with a deposit behind it.</description>
    <content:encoded><![CDATA[<p><strong>Track every returnable bottle as a running balance against the customer holding it — not as a line on an invoice.</strong> That single change is the whole system. Delivered minus returned, per customer, updated at the stop. Everything else in this article is detail on how to make that number reliable and what to do when it is wrong.</p>

<p>The reason it matters is that a 19 litre bottle is not stock you sold. It is an asset you lent, worth somewhere between Rs. 400 and Rs. 900 to replace, and you have hundreds of them walking around the city. A supplier running three routes with 600 customers can easily have Rs. 400,000 of polycarbonate outside the plant at any moment. Most cannot say what that number is to within 20%.</p>

<h2>Why the invoice model fails</h2>

<p>Almost every supplier starts by recording deliveries the way a shop records sales: customer, date, quantity, amount. That works perfectly for the money and not at all for the bottles, because a sale is a one-way movement and a bottle moves both ways.</p>

<p>The symptom is familiar. You know what you billed. You do not know what you are owed in glass. At stock-take you count what is in the plant, compare it against what you bought, and discover a gap of two hundred bottles with no way to attribute a single one of them to a customer, a rider or a month. So it gets written off, and the same thing happens next year.</p>

<h2>The three facts every stop must produce</h2>

<p>A delivery stop generates three numbers, and a system that captures fewer than three will be reconciled by guesswork later:</p>

<ul>
  <li><strong>Delivered</strong> — full bottles handed over.</li>
  <li><strong>Collected</strong> — empties taken back.</li>
  <li><strong>Paid</strong> — cash or transfer received at the door.</li>
</ul>

<p>Delivered and collected are usually equal on a settled account, which is exactly why they get treated as one number and written as "4". The day a customer takes four and returns three, that shorthand costs you a bottle, silently, and there is no record that it happened.</p>

<p>Record them separately, always, even when they match.</p>

<h2>Setting the opening balance</h2>

<p>This is the part that decides whether the whole system is worth anything, and it is the part everyone rushes.</p>

<p>Before you start tracking, you have to know how many bottles each customer currently holds. Not an estimate — a count. For a 600-customer round this takes a week of riders asking at each stop and writing the number down, and there is no shortcut. If you start from a guessed opening balance, every reconciliation afterwards is measured against a fiction, and within two months nobody will trust the report.</p>

<p>Two practical notes:</p>

<ul>
  <li>Do the count as part of the normal round, not as a separate exercise. A rider who is already at the door adds thirty seconds; a rider sent out specially adds a day.</li>
  <li>Where a customer disputes the number, write down <em>their</em> number and mark it disputed. You are establishing a starting point both sides accept, not winning an argument about the past.</li>
</ul>

<h2>Tying the deposit to the count</h2>

<p>A security deposit that is collected once and never compared against anything is decorative. The point of a deposit is the comparison.</p>

<p>Hold a deposit per customer, at a rate that reflects what a bottle actually costs to replace, and check it against their live bottle balance. Three states matter:</p>

<table>
  <thead>
    <tr><th>State</th><th>What it means</th><th>What to do</th></tr>
  </thead>
  <tbody>
    <tr><td>Deposit covers bottles held</td><td>Normal. You are protected.</td><td>Nothing.</td></tr>
    <tr><td>Bottles held exceed deposit</td><td>You are exposed for the difference.</td><td>Collect a top-up, or stop increasing their holding.</td></tr>
    <tr><td>Deposit exceeds bottles held</td><td>Usually a closed or shrinking account.</td><td>Refund the difference when they ask — and expect them to.</td></tr>
  </tbody>
</table>

<p>The second row is the one that pays for the system. A customer who has quietly accumulated eleven bottles against a four-bottle deposit is not a fraud; they are an account nobody looked at. Seeing it in a list, monthly, turns a future write-off into a phone call.</p>

<h2>Reconciling — and how often</h2>

<p>Reconciliation means comparing four numbers and explaining the difference:</p>

<ol>
  <li>Bottles issued from the plant to riders.</li>
  <li>Bottles recorded as delivered to customers.</li>
  <li>Bottles recorded as collected back.</li>
  <li>Bottles physically in the plant.</li>
</ol>

<p><strong>Do this daily, per rider, at the close of the round.</strong> A daily reconciliation surfaces a discrepancy of two bottles while the rider still remembers which stop was unusual. A monthly one surfaces a discrepancy of sixty, which nobody can explain and which therefore gets written off.</p>

<p>If daily is genuinely impossible, weekly on a fixed day beats monthly. What does not work is reconciling only when the numbers already look wrong — by then the trail is cold.</p>

<h3>Count on the same weekday</h3>

<p>Bottle positions swing with the delivery cycle. A plant counted on Friday and a plant counted on Monday are different businesses. Pick one weekday for the physical count and never move it, so month-on-month figures are actually comparable.</p>

<h2>Handling the awkward cases</h2>

<p><strong>Breakage.</strong> Record it as a written-off bottle against the customer or the rider, charged to the deposit or added to the invoice. What matters is that it is a recorded event with a name on it, so that monthly breakage becomes a number you can look at rather than a difference you discover.</p>

<p><strong>Bottles that come back damaged.</strong> Take them in — the customer's balance should reduce — and write them off separately as plant losses. Refusing them just means they get abandoned and you lose the bottle <em>and</em> the record.</p>

<p><strong>Customers who vanish.</strong> After a defined period with no delivery, an account with bottles outstanding should appear on a list by itself. Chasing a customer who left four months ago rarely works; chasing one who stopped three weeks ago often does. The difference is entirely how fast the list is produced.</p>

<p><strong>Shops and bulk customers.</strong> These return bottles irregularly and in quantity — twenty at once, then nothing for a fortnight. Their balance will swing wildly and that is normal. Judge them on the trend across a month, not on any single day's number.</p>

<h2>What good looks like</h2>

<p>A supplier with this working can answer these four questions without leaving their desk:</p>

<ul>
  <li>How many bottles are outside the plant right now?</li>
  <li>Which twenty customers hold the most, and is each one covered by a deposit?</li>
  <li>How many bottles did we lose last month, and to whom?</li>
  <li>Did yesterday's round balance, per rider?</li>
</ul>

<p>If any of those takes more than a minute, the count is not being kept — it is being reconstructed.</p>

<h2>Doing it in software</h2>

<p>All of this can be done on paper. A single-route supplier with sixty customers and a disciplined register will keep an accurate count for years, and should not buy software to do it.</p>

<p>It stops being possible somewhere around the second route and the third rider, because the daily reconciliation becomes an hour of arithmetic that nobody has time for, and the first thing dropped when a day gets busy is the thing that only pays off later.</p>

<p><a href="/features">Irsaal</a> keeps this balance automatically: the rider records delivered and collected separately at each stop, the customer's balance updates immediately, the deposit position sits next to it, and the round will not close until the rider's bottle and cash counts are accounted for. If you want to see the shape of it on your own customers, the <a href="/pricing">trial is fourteen days and takes no card</a>.</p>

<p>Related reading: <a href="/blog/reduce-bottle-loss-water-delivery">seven controls that actually reduce bottle loss</a> and <a href="/glossary">the glossary</a>, if any of the terms above were new.</p>]]></content:encoded>
    <category>Operations</category>
  </item>
  <item>
    <title>Starting a Water Delivery Business in Pakistan: What It Actually Takes</title>
    <link>https://irsaalsystems.com/blog/starting-a-water-delivery-business-in-pakistan</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/starting-a-water-delivery-business-in-pakistan</guid>
    <pubDate>Sat, 15 Aug 2026 19:22:12 +0000</pubDate>
    <description>Plant, bottles, a vehicle and a round. What each part costs, what order to buy it in, and the three mistakes that close most new suppliers inside two years.</description>
    <content:encoded><![CDATA[<p><strong>A small bottled-water delivery business in Pakistan needs three things before it needs anything else: a reliable water source you can treat, enough bottles to cover two delivery cycles, and a round of customers close enough together to serve profitably.</strong> Get those three right and the business works at almost any scale. Get the third one wrong and no amount of plant investment saves it.</p>

<p>This is a practical guide to what the parts cost, what order to buy them in, and where new suppliers actually lose money. It is written from what we see across the businesses using our software, not from a template.</p>

<h2>The four parts of the business</h2>

<h3>1. Treatment and filling</h3>

<p>You need to produce water that is safe, consistent and defensible. At the small end that means a filtration and UV or RO setup and a manual or semi-automatic filling line. At the larger end, an automated line with rinse, fill and cap in sequence.</p>

<p>The temptation is to spend here first, because it is the part that feels like the business. Resist it. A modest line that runs reliably and fills a round you already have is worth more than a large one waiting for customers.</p>

<h3>2. Bottles</h3>

<p>This is the part new entrants consistently underestimate. You do not need one bottle per customer — you need roughly <strong>two and a half to three per customer</strong>, because at any moment a bottle is either at the customer, in transit, or in the plant waiting to be filled.</p>

<p>A 400-customer round therefore needs somewhere around 1,000–1,200 bottles in circulation. At Pakistani replacement cost that is a serious sum, and it is capital that is permanently tied up. It is also the single largest asset you will fail to keep track of — see <a href="/blog/how-to-track-returnable-water-bottles">how to track returnable bottles</a>, because this is where most of the money quietly goes.</p>

<h3>3. Delivery</h3>

<p>A loading vehicle, a rider, and fuel. The economics here are all about density: a rider serving 80 stops within a few kilometres is profitable; the same rider serving 40 stops spread across the city is not, at any price you can charge.</p>

<p>This is why the third requirement — a geographically tight round — matters more than the plant. Ten customers in one lane are worth more than thirty scattered across a district.</p>

<h3>4. The office</h3>

<p>Someone has to take orders, raise bills, chase money and count bottles. At the start this is you. The mistake is assuming it stays free: by the third route it is a full-time job, and if nobody is doing it properly the business will look busy and profitable right up until the year-end count.</p>

<h2>Licences and compliance</h2>

<p>Requirements vary by province and change, so treat this as a checklist to verify locally rather than a definitive list. In broad terms, expect to deal with:</p>

<ul>
  <li>Business registration and an NTN.</li>
  <li>Provincial food-authority registration or licensing (Punjab Food Authority, Sindh Food Authority, and their equivalents).</li>
  <li>Water quality testing at defined intervals, with records kept.</li>
  <li>PSQCA marking requirements where they apply to your packaging and claims.</li>
  <li>Local trade licensing and any environmental or groundwater extraction permissions in your area.</li>
</ul>

<p>Verify each with the relevant authority before you commit capital. A plant that cannot be licensed is an expensive shed.</p>

<h2>Working capital: the number nobody plans for</h2>

<p>Here is the trap. You deliver all month and bill at month end. Customers pay through the following month, some of them late. Meanwhile you are buying caps, labels, electricity, fuel and wages weekly.</p>

<p><strong>Plan for at least two months of operating costs in working capital, on top of every asset purchase.</strong> Businesses that skip this do not fail because they are unprofitable; they fail because they are profitable and illiquid, which looks identical from the inside until the day wages are due.</p>

<h2>The three mistakes that close new suppliers</h2>

<h3>Mistake one: buying customers instead of building a round</h3>

<p>A new supplier takes any customer who calls, anywhere. Six months later there is a round with 200 customers spread across an area a rider cannot cover in a day, every stop is a long drive, and the fuel bill eats the margin. It is very hard to unwind, because saying no to existing customers is worse than never having taken them.</p>

<p>Build outward from a core. Turn down distant customers early, however painful, or price them to reflect what they actually cost.</p>

<h3>Mistake two: competing on price alone</h3>

<p>Water delivery has a real floor cost per bottle — treatment, cap, label, bottle depreciation, fuel, wage, and the amortised cost of the bottles that never come back. Undercutting the established supplier by a few rupees a bottle wins customers who will leave for the next few rupees, and it does it at a margin that cannot fund the bottles you need to buy.</p>

<p>Reliability wins in this market far more than price does. A household that has been let down twice in a heatwave will pay more, permanently, for a supplier who turns up.</p>

<h3>Mistake three: no control over the round</h3>

<p>The rider has the customer list, holds the stock, collects the cash and reports the day verbally. This is fine while there is one rider and you know every customer. It stops being fine the moment you cannot personally verify what happened, and the transition is invisible — you find out months later, from a count that does not balance.</p>

<p>Two controls fix most of it: a per-rider cash ledger closed at the end of every round, and a bottle count that reconciles daily.</p>

<h2>Sensible order of investment</h2>

<ol>
  <li><strong>Prove a round exists.</strong> Twenty committed customers in one area, served from a modest setup, tells you more than any market survey.</li>
  <li><strong>Buy bottles to depth, not width.</strong> Enough bottles for the customers you have, plus the cycle. Running out of empties is how you lose a customer.</li>
  <li><strong>Add the second rider before the second area.</strong> Densify what you have first.</li>
  <li><strong>Put controls in before the third route,</strong> not after the first loss. This is the point at which paper stops working.</li>
  <li><strong>Then scale the plant</strong> to the round you have actually built.</li>
</ol>

<h2>What to measure from day one</h2>

<ul>
  <li>Bottles outstanding, per customer and in total.</li>
  <li>Deliveries per rider per day, and stops per kilometre.</li>
  <li>Collection rate: what you billed against what you received, monthly.</li>
  <li>Bottle losses per month, as a number and as a cost.</li>
  <li>Customers gained and lost, monthly — churn tells you about reliability faster than any complaint does.</li>
</ul>

<p>Five numbers. If you know these, you are running the business. If you do not, the business is running.</p>

<p><a href="/">Irsaal</a> was built to produce exactly those five numbers for water suppliers in Pakistan, without anybody keeping a spreadsheet. The <a href="/pricing">trial is fourteen days, in rupees, with no card</a> — and if you are still at twenty customers with a register that balances, our honest advice is to come back at three routes.</p>]]></content:encoded>
    <category>Guides</category>
  </item>
  <item>
    <title>How to Price Water Delivery (And Why Your Rate Card Is Costing You)</title>
    <link>https://irsaalsystems.com/blog/how-to-price-water-delivery-pakistan</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/how-to-price-water-delivery-pakistan</guid>
    <pubDate>Thu, 06 Aug 2026 19:22:12 +0000</pubDate>
    <description>Work out your true cost per bottle first — including the ones that never come back — then decide what to charge. Most suppliers skip step one.</description>
    <content:encoded><![CDATA[<p><strong>Price from your cost per delivered bottle, not from what the supplier down the road charges.</strong> Almost no small water supplier knows their real figure, because the two largest components — bottle depreciation and bottle loss — do not appear on any bill they receive. Work those out and the correct price is usually obvious.</p>

<h2>The cost of one delivered bottle</h2>

<p>Add these up per 19 litre bottle delivered. Use your own figures; the point is the list, not the numbers.</p>

<table>
  <thead>
    <tr><th>Component</th><th>How to work it out</th></tr>
  </thead>
  <tbody>
    <tr><td>Water treatment</td><td>Monthly electricity, filters, membranes, chemicals and testing ÷ bottles filled.</td></tr>
    <tr><td>Cap and label</td><td>Direct, per fill.</td></tr>
    <tr><td>Bottle depreciation</td><td>Bottle cost ÷ realistic number of fills before it fails. A polycarbonate bottle in hard use gives far fewer cycles than the sales sheet claims.</td></tr>
    <tr><td>Bottle loss</td><td>Bottles that never came back last year × replacement cost ÷ bottles delivered last year. This is the one everybody omits.</td></tr>
    <tr><td>Delivery</td><td>Fuel, vehicle maintenance and rider wages ÷ bottles delivered. Falls sharply as route density rises.</td></tr>
    <tr><td>Office</td><td>Order taking, billing, chasing money, counting. Real, and rising with scale.</td></tr>
    <tr><td>Bad debt</td><td>Billed and never collected, as a percentage.</td></tr>
  </tbody>
</table>

<p>The last two rows are why suppliers who feel busy still have no cash. They are absolutely real costs and they appear nowhere in a per-bottle calculation done from purchase invoices alone.</p>

<h2>Why one price for everybody is the wrong answer</h2>

<p>A household taking two bottles a week from a dense residential lane and an office taking forty a week from an industrial estate ten kilometres out are not the same customer, and pricing them identically means one of them is subsidising the other.</p>

<p>Most established suppliers already run several rates. What they usually do not have is a <em>deliberate</em> structure — they have four tiers that emerged from four negotiations, live in one person's memory, and get applied inconsistently at invoice time.</p>

<p>A workable structure has three or four named tiers with a stated reason for each:</p>

<ul>
  <li><strong>Household</strong> — standard rate, standard deposit.</li>
  <li><strong>Bulk / commercial</strong> — lower per-bottle rate justified by volume per stop, with a correspondingly larger deposit because they hold more bottles.</li>
  <li><strong>Contract</strong> — offices and institutions billed monthly on invoice, priced for the payment terms as much as the volume.</li>
  <li><strong>Distant</strong> — a rate that reflects the actual cost of reaching them, or a minimum order that makes the trip worthwhile.</li>
</ul>

<p>Named tiers can be audited. "Whatever we agreed with them in 2023" cannot.</p>

<h2>Setting the deposit</h2>

<p>The deposit is not a revenue line and should not be priced like one. Its job is to make a lost bottle cost the customer roughly what it costs you.</p>

<p>Set it at or near replacement cost per bottle held, and scale it with the number of bottles the customer keeps. A customer who normally holds two bottles and one who holds fifteen should not carry the same deposit, and the second one is where suppliers get hurt.</p>

<p>Review deposits against actual holdings periodically — the account that has quietly grown from three bottles to eleven is common, and is exactly the exposure the deposit was supposed to cover.</p>

<h2>Raising prices without losing the round</h2>

<p>Input costs move. Prices have to follow, and suppliers who avoid the conversation for three years end up making one large increase, which is far more likely to lose customers than several small ones.</p>

<p>What works:</p>

<ul>
  <li><strong>Give notice in writing, a month ahead.</strong> A price rise that arrives on an invoice with no warning reads as an error or a trick.</li>
  <li><strong>Change one thing at a time.</strong> Raising the rate and the deposit in the same month makes both feel worse than they are.</li>
  <li><strong>Time it away from peak.</strong> A rise in the middle of a heatwave, when the customer needs you most, is remembered.</li>
  <li><strong>Say what it is for.</strong> "Bottle replacement costs have risen" is a reason. Silence invites the customer to supply their own.</li>
</ul>

<h2>The discounts you are giving without meaning to</h2>

<p>Three leaks, all common, all invisible on a rate card:</p>

<p><strong>The unbilled extra.</strong> A rider hands over an extra bottle "because they asked" and it does not reach the invoice. Individually trivial; across three routes and a month, not.</p>

<p><strong>The old rate that never moved.</strong> Long-standing customers on a rate from four years ago, kept because nobody wants the conversation. Run a list of customers by rate, sorted oldest first — the result is usually uncomfortable and always useful.</p>

<p><strong>The unreturned bottle.</strong> Every bottle written off is a discount you gave without deciding to. This is the largest of the three by a wide margin, and it is why <a href="/blog/reduce-bottle-loss-water-delivery">bottle loss</a> is a pricing problem and not only an operations one.</p>

<h2>A monthly check that takes ten minutes</h2>

<ol>
  <li>Total billed ÷ total bottles delivered = your actual average realised rate.</li>
  <li>Compare it against your standard rate. The gap is what your tiers, discounts and write-offs really cost.</li>
  <li>Compare your realised rate against your cost per delivered bottle from the table above.</li>
  <li>If the margin is thinner than you thought, the answer is far more often "collect what you are owed and stop losing bottles" than "charge more".</li>
</ol>

<p>Both of the numbers in step one should be a report you can open, not a calculation you have to build. In <a href="/features">Irsaal</a> they are — along with per-customer rates that apply themselves at invoice time, so the tier a customer is on is a fact rather than something somebody has to remember. <a href="/pricing">The trial is fourteen days and takes no card.</a></p>]]></content:encoded>
    <category>Money</category>
  </item>
  <item>
    <title>Seven Controls That Actually Reduce Bottle Loss</title>
    <link>https://irsaalsystems.com/blog/reduce-bottle-loss-water-delivery</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/reduce-bottle-loss-water-delivery</guid>
    <pubDate>Tue, 28 Jul 2026 19:22:12 +0000</pubDate>
    <description>Most bottle loss is not theft. It is accounts nobody looked at, rounds nobody reconciled and customers nobody chased. Seven fixes, in order of effect.</description>
    <content:encoded><![CDATA[<p><strong>Most bottle loss is administrative, not criminal.</strong> Bottles disappear into dormant accounts, unreconciled rounds and customers who moved house — not, in the main, into theft. That matters, because the fixes for an administrative problem are cheap and the fixes for a theft problem are not, and suppliers routinely spend on the second while the first goes untouched.</p>

<p>Here are seven controls, ordered by how much difference they make relative to how hard they are to put in.</p>

<h2>1. A balance per customer</h2>

<p>Everything else depends on this. Until each customer has a running count of bottles held — delivered minus returned — you have a total you cannot break down, and a total you cannot break down is a total you cannot act on.</p>

<p>Effect: largest of anything on this list. Effort: a one-week opening count, then nothing ongoing if the round records delivered and collected separately. Detail in <a href="/blog/how-to-track-returnable-water-bottles">how to track returnable bottles</a>.</p>

<h2>2. Deposits sized to actual holdings</h2>

<p>A deposit is only a control if it is compared against what the customer holds. Run a monthly list of accounts where bottles held exceed the deposit, sorted by the size of the gap.</p>

<p>The top twenty rows on that list are almost always where the losses are. They are rarely bad actors — they are accounts that grew and were never reviewed. A phone call and a deposit top-up closes most of them.</p>

<h2>3. Daily reconciliation per rider</h2>

<p>At the close of every round, compare: bottles issued to the rider, bottles recorded delivered, bottles recorded collected, bottles returned to the plant. The difference should be zero.</p>

<p>The point is not catching anybody. It is the timing. A two-bottle gap found the same evening gets explained — a wrong entry, a stop that took an extra bottle, a bottle left at the gate. The same gap found at month end is sixty bottles with no explanation available.</p>

<p>Riders adjust quickly to a round that is counted daily, and that adjustment is most of the benefit.</p>

<h2>4. A dormant-account list</h2>

<p>Any customer with bottles outstanding and no delivery in — pick a number — six weeks should appear automatically on a list.</p>

<p>People move, businesses close, customers switch supplier without mentioning it. Bottles go with them. Recovery at three weeks is routine; recovery at six months is rare. The entire difference is how quickly the list is produced, which is why this should be automatic and not something somebody remembers to check.</p>

<h2>5. Recorded write-offs</h2>

<p>When a bottle is broken, damaged beyond use or agreed as lost, record it as a written-off bottle against the customer or rider it relates to, and settle it against the deposit or the invoice.</p>

<p>The value is not the recovery — it is that write-offs become a monthly number with names attached. A route that writes off four times as many bottles as its neighbours is telling you something, and that signal is completely invisible if losses are only ever a difference at stock-take.</p>

<h2>6. A physical count on a fixed weekday</h2>

<p>Count the plant on the same weekday every time. Bottle positions swing with the delivery cycle, so a Friday count and a Monday count describe different businesses and comparing them produces noise that looks like loss.</p>

<p>Monthly is enough if the daily rider reconciliation is happening. If it is not, monthly is the only real control you have and it should be fortnightly.</p>

<h2>7. Return terms customers actually know about</h2>

<p>Much of what looks like customer-side loss is customers not knowing the rules. Put the terms on the invoice, in plain language, in the language they read:</p>

<ul>
  <li>How many bottles they are expected to hold.</li>
  <li>What the deposit covers.</li>
  <li>What happens to the deposit when they stop.</li>
  <li>Who to tell when they move.</li>
</ul>

<p>The last one is worth more than it looks. A customer who knows to call before moving usually does; a customer who has never been told simply leaves, with your bottles.</p>

<h2>What a realistic result looks like</h2>

<p>Suppliers who put in the first three controls generally find two things. The number is worse than they thought — the loss they had accepted as normal was larger than their estimate. And it falls quickly, because a large share of it was accounts and rounds that nobody was looking at rather than bottles genuinely gone.</p>

<p>The residual loss after that is the real, unavoidable rate for your market: breakage, genuine disappearance, customers who leave without warning. Know what it is, cost it into your <a href="/blog/how-to-price-water-delivery-pakistan">price per bottle</a>, and stop being surprised by it once a year.</p>

<p>Controls 1 through 5 are automatic in <a href="/features">Irsaal</a>: the balance is kept at the stop, the deposit gap is a list, the round will not close until it reconciles, dormant accounts surface by themselves and write-offs are recorded events. <a href="/pricing">Fourteen days free, no card.</a></p>]]></content:encoded>
    <category>Operations</category>
  </item>
  <item>
    <title>Route Planning for Delivery Rounds: Density Beats Distance</title>
    <link>https://irsaalsystems.com/blog/delivery-route-planning-water-suppliers</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/delivery-route-planning-water-suppliers</guid>
    <pubDate>Sun, 19 Jul 2026 19:22:12 +0000</pubDate>
    <description>The number that decides whether a round is profitable is stops per kilometre — not stops per day. How to build routes around it, and when to say no to a customer.</description>
    <content:encoded><![CDATA[<p><strong>Build routes around density — stops per kilometre — not around area or customer count.</strong> A rider serving 70 stops in a tight residential block earns money; the same rider serving 45 stops spread across a district loses it, at any price you can realistically charge. Every other route decision follows from that one.</p>

<h2>Why density is the number</h2>

<p>A delivery day is made of two things: time at stops and time between them. Time at stops is roughly fixed — handing over bottles, taking empties, collecting money, a word with the customer. Time between them is entirely a function of how far apart they are.</p>

<p>Increase density and you convert travel time into delivery time, which is the only time that produces revenue. This is why adding customers inside an existing route is close to free while adding the same number of customers three kilometres away requires another rider.</p>

<h2>Building a route from scratch</h2>

<h3>Start from a natural boundary</h3>

<p>Cities have edges that riders cannot cross quickly: a canal, a railway line, a motorway, a market. Use them as route boundaries. A route that spans a barrier will always cost more than the map suggests, because the map does not show the twenty minutes it takes to get around it.</p>

<h3>Sequence for one-way movement</h3>

<p>Order the stops so the round moves outward and back, or in a loop, and never crosses itself. The most common failure in hand-built routes is a sequence that zigzags — usually because it was built in the order customers signed up rather than in the order they should be visited.</p>

<p>Rebuilding the sequence from scratch is worth doing annually. Rounds accumulate history.</p>

<h3>Size it to a real day</h3>

<p>A round should finish with time to spare, not exactly at closing. Rounds sized to a perfect day fail on every ordinary one — a puncture, a locked gate, a customer who wants to talk — and the failure lands on the last customers on the list, who are the same customers every time. Those customers churn, and nobody connects it to route sizing.</p>

<h2>When to split a route</h2>

<p>Four signals, any of which is enough:</p>

<ul>
  <li>The round is regularly finishing late, or the last stops are regularly being pushed to tomorrow.</li>
  <li>Fuel per delivered bottle is rising on that route while others are flat.</li>
  <li>Customer complaints cluster at one end of the sequence.</li>
  <li>The rider is skipping the reconciliation because there is no time at the end of the day.</li>
</ul>

<p>Split by geography, not by cutting the list in half. Two compact halves work; two interleaved halves double the travel and halve nothing.</p>

<h2>The distant customer problem</h2>

<p>Every supplier has them: good customers, reliable payers, ten kilometres from anything else. They feel valuable because the revenue is visible and the cost is not.</p>

<p>Three honest options:</p>

<ol>
  <li><strong>Price for it.</strong> A distant tier, or a minimum order that makes the trip worthwhile. Say so plainly; most customers understand.</li>
  <li><strong>Batch it.</strong> Serve that area on one fixed day a week, and put every distant customer on that day. A weekly route to one area is viable where a daily detour is not.</li>
  <li><strong>Let them go.</strong> Genuinely the right answer sometimes, and much easier at ten customers than at eighty.</li>
</ol>

<p>What does not work is absorbing the cost quietly and wondering why the margin on that route is poor.</p>

<h2>Schedules, not orders</h2>

<p>Most delivery customers are predictable: the same quantity, on the same days. Building the round from standing schedules rather than from orders taken each day removes the largest source of daily office work and the largest source of missed stops.</p>

<p>The exceptions — a customer away for a week, a shop that doubles in summer — are recorded against the schedule as changes, not by rebuilding the round. This distinction is worth more than it sounds: a system built on orders needs someone entering the same thing every day, and the day they are ill, the round is wrong.</p>

<h2>What to measure per route</h2>

<table>
  <thead>
    <tr><th>Measure</th><th>Why it matters</th></tr>
  </thead>
  <tbody>
    <tr><td>Stops completed per day</td><td>Capacity. Compare against the plan, not against other routes.</td></tr>
    <tr><td>Bottles delivered per stop</td><td>Tells you whether a route is household or commercial in character.</td></tr>
    <tr><td>Fuel per delivered bottle</td><td>The density measure that needs no map. Rising means the route is spreading.</td></tr>
    <tr><td>Collection rate</td><td>Routes differ enormously here, and it is usually about the rider.</td></tr>
    <tr><td>Bottle variance</td><td>A route consistently short is a route to look at, not a rider to accuse.</td></tr>
    <tr><td>Customers lost per quarter</td><td>The earliest signal that a route is over-sized.</td></tr>
  </tbody>
</table>

<h2>The rider's day, from their side</h2>

<p>A route plan that ignores the rider fails. Three things make the difference between a plan that is followed and one that is quietly reordered every morning:</p>

<ul>
  <li><strong>The sequence has to make sense on the ground.</strong> If the rider reorders it daily, the plan is wrong and they are right — go and drive it.</li>
  <li><strong>Recording has to be fast and work offline.</strong> Three taps at the stop. A rider who has to wait for a signal at every gate will record the whole round from memory at the end of the day, and that round is fiction.</li>
  <li><strong>The close has to be quick.</strong> If reconciling takes twenty minutes at the end of a nine-hour day, it will not happen. Make it two.</li>
</ul>

<p><a href="/features">Irsaal</a> builds the round from each customer's standing schedule, keeps the sequence with the route rather than in a rider's head, and records each stop offline so a weak-signal area does not cost you the day's data. <a href="/pricing">Fourteen days free, no card required.</a></p>]]></content:encoded>
    <category>Operations</category>
  </item>
  <item>
    <title>Recovery: How to Collect What You Are Already Owed</title>
    <link>https://irsaalsystems.com/blog/recovery-collecting-overdue-balances-delivery</link>
    <guid isPermaLink="true">https://irsaalsystems.com/blog/recovery-collecting-overdue-balances-delivery</guid>
    <pubDate>Fri, 10 Jul 2026 19:22:12 +0000</pubDate>
    <description>The delivery already happened, so the leverage is gone. What is left is speed, order and consistency — and an ageing list that tells you who to call first.</description>
    <content:encoded><![CDATA[<p><strong>Chase by age, not by amount.</strong> A balance at 90 days is a fundamentally different problem from the same balance at 30, and treating them the same is why suppliers end up writing off money they could have collected. Sort your overdue list by how long it has been outstanding, work down it, and the recovery rate improves before you change anything else.</p>

<h2>Why recovery is its own job</h2>

<p>In a delivery business the goods are gone before the money arrives. There is no order to withhold, no shipment to stop — the water has been drunk. Whatever leverage existed disappeared at the doorstep.</p>

<p>What is left is process: finding out quickly, asking consistently, and escalating in a predictable order. None of that is about persuasion. It is about not letting a balance get old, because the probability of collection falls with age far faster than most suppliers expect.</p>

<h2>Ageing buckets</h2>

<p>Split every outstanding balance into four groups:</p>

<table>
  <thead>
    <tr><th>Bucket</th><th>What it usually means</th><th>Action</th></tr>
  </thead>
  <tbody>
    <tr><td>Current</td><td>Billed, not yet due.</td><td>Nothing.</td></tr>
    <tr><td>1–30 days</td><td>Forgot, or waiting for their own money.</td><td>One reminder. Friendly, on WhatsApp.</td></tr>
    <tr><td>31–60 days</td><td>A pattern, not an oversight.</td><td>A call, and a specific date agreed.</td></tr>
    <tr><td>60+ days</td><td>Either a real problem or a customer who has learned you do not chase.</td><td>Decision: payment plan, stop supply, or write off.</td></tr>
  </tbody>
</table>

<p>The bucket that matters most is 31–60. It is where a customer decides whether you are a supplier who follows up. Suppliers who are consistent here find their 60+ bucket shrinks on its own, because customers pay whoever chases first.</p>

<h2>The order to work the list</h2>

<ol>
  <li><strong>Oldest first</strong>, always. The clock is the enemy.</li>
  <li>Within the same age, <strong>largest first</strong> — the effort is the same either way.</li>
  <li><strong>Accounts still being supplied before accounts already stopped.</strong> A customer still receiving deliveries has a reason to settle; one already cut off has a reason to argue.</li>
</ol>

<h2>Collecting on the round</h2>

<p>The rider is at the customer's door every week. That is the cheapest collection channel there is and most suppliers underuse it.</p>

<p>What makes it work:</p>

<ul>
  <li><strong>The rider can see the balance at the stop.</strong> A rider who does not know the account is overdue cannot mention it.</li>
  <li><strong>Every payment is recorded at the door,</strong> not written on a slip and entered that evening. The gap between collection and record is where money goes missing, and it is almost never dishonesty — it is a full pocket and a long day.</li>
  <li><strong>A per-rider cash ledger that closes daily.</strong> What the round should have collected, what was handed in, and the difference — every day, per rider. This is the single most effective control in a cash delivery business.</li>
  <li><strong>Riders do not negotiate.</strong> They ask, they record, and anything beyond "yes" or "next week" goes to the office. A rider who agrees terms at the door is a rider being put in an impossible position.</li>
</ul>

<h2>Asking, in practice</h2>

<p>Two things work more than anything else, and neither is about pressure.</p>

<p><strong>Ask for a specific date.</strong> "When can we expect it?" produces a commitment. "Please pay soon" produces nothing. Write the date down, and follow up on it — following up on the date the customer chose is a completely different conversation from chasing in general.</p>

<p><strong>Make paying easy.</strong> Bank transfer, JazzCash, Easypaisa, cash to the rider. Every step between the customer's intention and the money moving is a step at which the intention expires.</p>

<h2>When to stop supplying</h2>

<p>Have a rule, write it down, and apply it the same way to everybody. Something like: no new deliveries above a stated balance or beyond a stated age, without a manager's approval.</p>

<p>A written rule turns a confrontation into a policy. "I am not allowed to leave bottles above this balance" is a much easier sentence for a rider to say than "you have not paid", and it is much harder for a customer to take personally.</p>

<p>Applying it inconsistently is worse than not having it, because it teaches customers that the rule depends on who is asking.</p>

<h2>Bottles are the other half</h2>

<p>An overdue customer is usually also holding your bottles, and the bottles are frequently worth more than the balance. Recovery is not finished when the money is settled — collect the bottles, or set the deposit against what is owed and close the account properly.</p>

<p>See <a href="/blog/how-to-track-returnable-water-bottles">tracking returnable bottles</a> for the mechanics of getting that number right in the first place.</p>

<h2>Four numbers to watch monthly</h2>

<ul>
  <li><strong>Collection rate</strong> — received ÷ billed, for the month.</li>
  <li><strong>Days sales outstanding</strong> — how long, on average, money takes to arrive.</li>
  <li><strong>The 60+ bucket</strong> — as a figure and as a share of total outstanding.</li>
  <li><strong>Collection rate by rider</strong> — this varies far more than anyone expects, and it is the most actionable number on the list.</li>
</ul>

<p>All four should be reports you open, not calculations you build. In <a href="/features">Irsaal</a> they are, alongside an ageing list that orders itself and a per-rider cash ledger that closes at the end of every round. <a href="/pricing">Fourteen days free, no card.</a></p>]]></content:encoded>
    <category>Money</category>
  </item>
</channel>
</rss>