An invoice app for small business is a numbering system with a PDF attached.
Most of what people want from an invoice app for small business is not design. It is that the number on the invoice is unique, that the total never changes after it is sent, and that the client can pay it without a phone call. The same discipline runs through estimate apps for contractors, which is where a lot of invoices start life.
This page covers what an invoice has to carry, what Apple actually allows when you collect payment, how the PDF gets off the phone and into a client's inbox, and the parts of the job nobody budgets for.
Work out what the client owesThe short version
An invoice is a record of a debt, not a document you tidy up later.
Two things separate an invoicing app from a form that makes a nice PDF. Numbers allocated once and never reused, and totals frozen at the moment of issue. Most of the rest is layout.
Get those wrong and the app works beautifully for a year, then fails in the one week it matters, when somebody asks you to explain a figure from last March.
What an invoice carries, and what it must never do
Every invoice is the same short list of facts. A number, an issue date, who is billing, who is being billed, what was done, the amounts, any tax, the total, the due date and how to pay. A small business invoicing app that holds those ten things properly already beats a spreadsheet emailed at nine in the evening.
The number is the part people get wrong. It must be unique, it should not skip without a reason you can explain, and it must never be reused. A sent invoice is already out in the world. If the amount was wrong you do not edit it, you issue a credit note and then a fresh invoice. An app that lets the owner quietly correct one destroys the trail an accountant needs later.
Totals have to be stored, not recalculated. Keep only the hours and a pointer to your current rate, and raising that rate next spring rewrites every invoice you sent last year. Store the line items, the rate used, the tax rate used and the computed total, as they stood on the day. Hold money as whole cents, and round in one place, by a rule you wrote down.
Most line items started life as costs. Materials, mileage, parking and a permit fee were receipts first, which is the job of a business expense tracking app. The link worth building turns a billable cost into a line without anybody retyping it.
Try it
What the client owes
Every number here is stored on the invoice the moment it is issued, not worked out again later from whatever the rate happens to be then.
Labour, 6 hours at 85$510.00
Materials, billed at cost$240.00
Tax at 8.5% on the subtotal$63.75
$613.75 due
Subtotal $750.00, less a deposit of $200.00. Tax is rounded once, on the subtotal. Rounding each line separately gives a different answer, so pick one rule and write it down.
Getting paid, and what Apple actually allows
Nothing on the page matters as much as the payment instruction. A mobile invoice app that ends with bank details in plain text still leaves the client to open a banking app and type them in. A link they tap while the invoice is open gets paid sooner, and there is nothing to mistype.
People building this are often warned that Apple takes a cut of any money moving through an iPhone app. For work done in the real world, the App Store Review Guidelines say close to the opposite. Guideline 3.1.3(e) covers goods and services outside the app. If your app lets people buy physical goods or services consumed outside of it, you must collect payment by a method other than in app purchase, such as Apple Pay or ordinary credit card entry. A roof, a haircut and a pallet of tiles are all outside the app.
So the payment side is a normal card processor, not an App Store transaction. Most small teams never build a card form at all. They create a hosted payment link with their processor, put it on the invoice, and let the processor handle cards, receipts and refunds. The app records that an invoice was marked paid, by whom and when.
Collecting payment for the work is a separate question from charging for the app itself, which has its own rules and is the one place where in app purchase really does apply.
App Store Review Guidelines, 3.1.3(e) goods and services outside the app
The invoice has to leave the phone
An invoice that only exists inside your app is not an invoice. It has to arrive as something the client can open, forward to their bookkeeper and print. In practice that means a PDF, and on a phone it means the PDF has to reach Mail, Files or whatever the client actually uses.
The normal route in a React Native project has two steps. Render the invoice as HTML, hand it to a print module that writes a PDF into the app cache directory, then pass that file path to the system share sheet. Expo documents both steps. On iOS that sheet is the standard one, so Mail and Save to Files sit in it.
One caveat if an AI app builder writes this. The Newly documentation lists what a new project starts with: video and audio, SQLite, secure storage, Skia, Reanimated, bottom sheets and MMKV. Nothing for printing or sharing is on it. A PDF export therefore adds a package, and a package that is not already installed triggers a native build of several minutes. We did not run that build and watch an invoice reach Mail, so treat share to email and Files as ordinary iOS behaviour, not something we confirmed. The same docs say preview builds install only on the cloud simulators, so a real test needs TestFlight on a phone.
There is a second decision hiding in that share sheet. Sending the email from a server means a sending domain, spam filters, and replies going to a machine nobody reads. Share the PDF into the owner's own mail app instead and it comes from an address the client knows, with replies landing in the right inbox. Less impressive, usually right.
The parts nobody budgets for
Tax is the first surprise. One rate for everything holds until you bill a product and a service on the same invoice, or work across a state line. Decide early whether tax sits on the line or on the invoice, because changing your mind later means rewriting every total you already stored.
Chasing is the second. An invoice app for contractors earns its keep on day thirty one, not day one. You want a list of what is overdue and by how long, a reminder that goes out without anyone having to decide to be rude, and a record of when each reminder was sent. Most money lost to late payment is lost because nobody asked.
The client side is the third. Emailing a PDF is fine for one job a year. For a client you bill every month, a client portal app that lists their invoices, shows what is outstanding and holds the payment link removes a whole category of requests to resend the one from July.
The fourth is that phones lose signal and businesses get audited. An invoice written in a basement has to survive the ride back to daylight, so write locally first and sync afterwards. The records also have to outlive the phone, which means a real backup and an export an accountant can read.
What each way of invoicing actually gives you
| Option | Works at the job | Numbering you can trust | Payment link on the invoice | Fits your own line items |
|---|---|---|---|---|
| Paper duplicate book | Yes | by hand | No | Yes |
| Word template emailed later | at a desk | by hand | No | Yes |
| Invoicing app subscription | Yes | Yes | Yes | its fields, not yours |
| Accounting suite module | Yes | Yes | Yes | its fields, not yours |
| An invoice app you build | Yes | Yes | through a processor | Yes |
Building one around the way you actually bill
Off the shelf invoicing is cheap and it works. People still build, and the reason is almost always one field the subscription does not have. A retention percentage held back until sign off. A rate that changes after the fourth hour on site. Two businesses billed from one phone. A client who insists their purchase order number appears in a particular place. Each is a short conversation with a developer and an impossible one with a settings screen.
Newly is an AI app builder. You describe the app, including the way you bill, and it writes a real React Native project you own and runs it on a cloud simulator while it builds. It costs $25 a month and there is no free plan. It does not ship a payment processor or a general ledger, and iOS builds go out through TestFlight using your own Apple developer account. Reach for it when the subscription almost fits and the gap is the part you bill on.
Before any of that, settle two rules on paper: how a number gets allocated, and what happens to an invoice that turns out to be wrong. Almost everything else is a form.
Questions people ask about invoice apps
A unique number, the issue date, both parties, a description of the work, the amounts, any tax, the total, the due date and a way to pay. Two behaviours matter more than the fields. Numbers are never reused, and the total is stored as it stood on the day of issue.
Describe how you actually bill
Write down your numbering rule, the one line item nobody else supports, and what happens when an invoice turns out to be wrong. Build the app around those three answers.
Start building