Recurring Invoices & the Customer Portal

Recurring invoices are reached from the Recurring invoices link at the top of Sales → Invoices. A schedule names a customer, a set of lines and a cadence — weekly, monthly, quarterly or annually. You set First invoice on, the date of the first period, and optionally a last date; leave it empty and the schedule runs until you end it. Due after defaults to 14 days. If the lines include stock items, choose the warehouse to ship from and optionally a location in it. A user tied to one warehouse can only set their own. A recurring invoice is built by the same code as one you type, so it takes the same numbering, tax, credit check and eTIMS filing.

Two details shape what the invoices say. First, a line with a blank unit price is priced from the customer’s price list on each invoice date, while a typed price is fixed — so a price-list change reaches the next run only on lines left blank. Second, periods are counted from the first invoice date, not chained from the last run: a schedule that starts on the 31st bills on the last day of February and then on the 31st again, rather than drifting to the 28th. And a start date in the past back-bills: until a schedule has raised its first invoice, a past first date raises one invoice for every period from then to today, each dated to its own period. The form warns you how many before you save.

In practice: a property manager in Westlands sets up “Office rent — Block B” for a company leasing the floor, monthly, first invoice on 31 January 2026, due after 7 days, one service line typed at KES 85,000 plus 16% VAT — KES 98,600 an invoice. The invoices fall on 31 January, 28 February and 31 March. A colleague setting up a cleaning contract on 2 October with a first date of 1 January is warned that ten invoices will be raised, January to October, each dated to its own month — which is either exactly what she wants or a costly typo to catch before saving.

Each schedule chooses how its invoices are delivered. With neither box ticked, each invoice is raised as a draft for someone to review and approve. Issue automatically approves each invoice as it is raised, which is when it files to eTIMS where that is switched on. Issue automatically and Email it to the customer also emails the invoice PDF to the customer’s address on file once it is issued. Emailing needs automatic issue, because a draft is not final, so a schedule with email ticked and issue unticked is refused.

Automatic issue never bills stock that is not free. If the goods for a period are short at the schedule’s warehouse after other orders’ reservations, the invoice is still raised on time but left as a draft, and whoever created the schedule is notified with what was short. An invoice that would take the customer over their credit limit goes on credit hold like any other and waits for an override. If an issued invoice cannot be emailed — the customer has no valid email address — the invoice stands and the creator is notified. On the ledger a recurring invoice posts exactly as a typed one: service lines book receivable, revenue and tax payable at issue; stock lines book revenue and cost of sales at checkout; a draft posts nothing until approved.

In practice: a water-dispenser company runs a monthly schedule for a school in Kisumu — one service line for rental at KES 4,500 and a stock line for 20 bottles from the Kisumu depot, set to issue and email. In March the depot has only 12 bottles free after other orders are reserved. The March invoice is raised on its date but left as a draft, and the person who built the schedule sees a notification naming the bottles that were short. Once stock arrives they approve the draft by hand; the April invoice goes out on its own as usual.

Every morning the system raises the invoices that are due. Each schedule raises one invoice per period, ever: a second run, a retry or a double click cannot raise a duplicate. Periods missed while the system was down are raised when it is back, each dated to its own period, up to 12 per schedule per run, so a longer backlog finishes on the following mornings. A schedule also ends by itself once its last invoice date has passed.

A failure does not skip a month. If a period cannot be raised, the error is recorded on the schedule, the schedule stays where it was, and the same period is retried on the next daily run; the creator is notified the first time it fails, not every morning. Managing a schedule uses four actions. Raise next now raises the next period’s invoice today, whatever its date — the same period the daily run would have raised, so it is never raised twice. Pause stops billing, and periods that fall while paused are skipped, not billed; on resume it picks up at its next date from today. End schedule is final: an ended schedule cannot be edited or resumed. Editing changes lines, delivery and dates, and once an invoice has been raised a change of start date or cadence recounts the next date from the last invoice raised.

In practice: a monthly retainer bills on the 1st. The client asks for a break, so the account manager pauses it on 10 March and resumes on 20 May. The April and May periods are skipped, not stored up, and the next invoice is 1 June. Had she meant only to delay April’s bill, the right tool was to leave the schedule active and adjust the schedule instead. The schedule page lists every period raised with its invoice, total and status — and the error text for any period that failed, which is where to look when a customer says a month never arrived.

The customer portal is reached from the Customer portal link at the top of Sales → Quotes. That screen lists everyone with portal access, which customer they belong to, when they last signed in and whether their access is active, and shows the portal address to share. Invite someone asks for the customer, the person’s name and their email, and sends an email from your organization with a sign-in link. Several people from one customer can each have their own access, but one email address belongs to one customer in your portal: an address that already has access for a different customer is refused, and inviting an address that already belongs to the same customer updates the name and sends a fresh link.

There is no password. The customer enters their email on the portal sign-in page and is sent a link that works once and expires in 30 minutes. Opening it shows a button to finish signing in, so email security scanners that open links cannot use it up first. The sign-in page gives the same answer whether or not an address has access and limits how many links one address can request, so it cannot be used to discover who your customers are or to flood an inbox. A browser already signed in to your staff workspace or the vendor portal is asked to sign out first or use a private window. Inviting, resending and revoking all sit behind one permission, managing the customer portal, and the same actions are in the mobile app.

In practice: an accounts officer invites the finance lead and the procurement officer at a Nakuru flower farm, each with their own email. The procurement officer opens his invitation the next day, after its 30 minutes are up, so she clicks Resend link. When the finance lead later leaves the farm, she clicks Revoke: his access ends at once, he is signed out on his next click, and every link already sent to him stops working. If he returns, inviting him again with the same email restores access.

Every portal page shows only that one customer’s records with your organization, under your name and logo. The overview shows what they owe in total, how much is overdue, recent invoices and quotes waiting for an answer. Invoices lists what you have issued to them — drafts and invoices on credit hold are not shown — each with its lines, payments and a downloadable PDF. The statement shows invoices, payments and credit notes with opening, running and closing balances, for the last six months by default or dates they choose. Quotes lists every quote you have sent them; an open one can be accepted or declined with an optional note, recorded under the signed-in person’s name, and the quote’s author is notified. Credit notes shows issued and applied credit notes.

Customers can pay all or part of an invoice’s balance from the invoice page. M-Pesa sends a prompt to the phone number they enter; card takes them to Paystack’s payment page and back to the invoice afterwards. Money goes to your own connected M-Pesa and Paystack accounts, set up under Settings → Finance & Tax → Payment Settings. Each option appears only when that gateway is connected and active, for an invoice in Kenyan shillings with a balance of at least 1. A payment is recorded against the invoice only when M-Pesa or the card network confirms it, not when the customer clicks pay. The portal itself posts nothing; a confirmed payment reduces the invoice’s balance like any other customer payment.

In practice: the flower farm’s finance lead signs in and sees KES 312,400 owing, of which KES 86,000 is overdue. She opens the overdue invoice, pays KES 50,000 of it by M-Pesa from the farm’s phone, and approves the prompt; once M-Pesa confirms, the invoice shows KES 36,000 still due. She then accepts a pending quote for new cold-room packaging with the note “deliver after the 15th”. A USD invoice to the farm’s export arm shows no pay buttons at all, because the portal’s gateways take Kenyan shillings only — that one is paid by bank transfer and recorded by your staff.