⚡ AI Analyst
Build an invoice app without code using Lovable: the prompts that work, numbering and access rules, real email limits and what it costs in 2026.
Money Flock
Recommended Contents
Comments
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.
An invoice is the least glamorous financial document in a business and the one auditors look at first. It is a claim: this much, for this work, owed by this date. Everything about it that matters is boring. The number has to be unique. The total has to match the line items. The client has to be able to see their own invoice and nobody else's. The date it was issued cannot quietly move.
Which is why the spreadsheet template most freelancers and small firms start with survives far longer than it should. It produces something that looks like an invoice. It does not produce a record. Two people open the same file on the same afternoon and one of them wins. A number gets reused. A paid flag gets flipped back by accident. Nothing announces the problem until the year-end reconciliation refuses to balance.
This guide walks through how to build an invoice app without code using Lovable, a platform where you describe the app you want in plain language and it writes and hosts the code. The claim in the headline is that it takes an afternoon, and for the first working version that is broadly true. The part that takes longer, and that almost no tutorial covers, is the set of rules that turn a generator of pretty PDFs into something you would be willing to hand an accountant. Every price and limit below was read from Lovable's own pages on 25 September 2026 and is dated where it appears.
Start by separating the document from the record. A template makes a document. An app has to maintain a record, and a record has obligations a document does not.
A spreadsheet does none of these. A generic invoice-generator tool usually does the first and the fourth, and leaves the second and third to trust. The reason to build your own is that you get to decide all four, and that is also the reason the build is worth more than an afternoon of attention.
Lovable gives you the application, the database, authentication, file storage, scheduled background jobs and transactional email in one place, so the invoice app is not a front end hunting for a backend. What it does not give you is an opinion about accounting. It will happily build an invoice number field you can edit, because you asked for an invoice number field. The correctness has to come from the prompt.
| In the spreadsheet | In the invoice app | Why the change matters |
|---|---|---|
| A cell you type the invoice number into | A number the database issues on creation | The same number cannot be used twice, even by two people at once |
| A row you edit after sending | A sent invoice that is read only, plus a credit note | The history of what the client received survives |
| A Paid column somebody ticks | A payment record with an amount, a date and an author | You can answer who marked it paid and when |
| A tab per client | One table with per-user access rules | A client link shows that client and nothing else |
| A file emailed as an attachment | A stored PDF with a controlled link | The document the client has is the document you issued |
| Totals that recalculate when a cell moves | Totals computed once and stored on the invoice | A historic invoice does not change when your rates do |
Each of these is one sentence in the prompt and a week of rework if you skip it.
There are three plausible answers: only you, you plus named teammates, or you plus the client the invoice belongs to. The third is the one that turns an internal tool into a client-facing one, and it is the one that has to be enforced at the database layer with row level security rather than by hiding a button. This is the single most common failure in apps built quickly on any platform, and it is covered in depth in is Lovable safe for financial data. Decide it now, because retrofitting access rules onto a table that already has rows is the hard version.
Pick a scheme and state it: a running integer, a per-year sequence that resets, or a prefix per client. Then state the part people forget, which is that the app issues it and nobody types it. If your tax authority expects gapless sequential numbering, say so in the prompt, and say what happens to a cancelled invoice, because deleting one leaves a gap that you will later have to explain.
Give the invoice a status and define the transitions. A draft is editable. A sent invoice is not. A paid invoice carries a payment record. Voiding produces a credit note rather than a deletion. Four words in the prompt here save a rebuild later.
The PDF is a file, and files need a home and an access rule of their own, separate from the database row. More on this below, because Lovable's defaults here are stricter than most people expect and that is good news.
Store amounts in the smallest unit of the currency as integers rather than as decimals, and store the currency code on the invoice rather than assuming one. Say whether tax is a line, a rate applied to the subtotal, or absent. Rounding rules belong in the prompt because the alternative is discovering them in a dispute.
What follows is the order that produces the fewest rebuilds. You can start from Lovable's free plan to see whether the shape is right, with one important caveat about email that the cost section covers.
Ask for the data model and one screen, not for the whole product. A first prompt worth typing looks like this:
"Build an invoicing app for a small services business. Clients have a name, billing email, address and default currency. An invoice belongs to one client and has an issue date, a due date, a currency, line items with description, quantity and unit price, and a status of draft, sent, paid or void. The app issues the invoice number on creation as a per-year sequence like 2026-0001 and nobody can type or edit it. Totals are calculated from the line items and stored on the invoice. A sent invoice is read only; changing one creates a credit note instead. Give me a list view with status filters and a single invoice view."
Notice how much of that is rules rather than screens. The screens are the easy part and Lovable is good at them. The rules are what you are actually buying with the prompt.
Second prompt, before any client record exists: state who can read and write what. Ask for the policies to be created in the database and ask Lovable to show you them. Then test the failure case yourself by signing in as a second account and trying to open an invoice you do not own. An access rule you have not tried to break is a hypothesis.
Lovable's own prompt library documents this one, which is a useful signal that it is a supported path rather than a hopeful one. Its published example asks for a download button on the invoice view that generates a PDF matching the on-screen invoice with logo, line items, totals and payment details, names the file with the invoice number, and paginates long item lists cleanly. That last clause is the one people leave out and then rediscover on a twenty-line invoice.
An invoice that arrives from a generic sending address is an invoice that lands in spam. Lovable can send transactional email from a domain you control and sets up the authentication records for you, including SPF, DKIM and DMARC, then keeps checking them and marks the domain Offline if they change. You do not need a separate email provider account or API key for this. If you already run your sending elsewhere, there are connectors for the usual providers instead.
One detail specific to invoicing: Lovable adds an unsubscribe link to the footer of app emails automatically, and tells you not to add your own. On a marketing newsletter that is correct behaviour. On an invoice it is worth knowing about before a client clicks it and wonders whether they have just opted out of being billed.
Scheduled background jobs run in the app's backend on a timetable, and the documented example is almost exactly the invoice case: a job that runs each morning, finds records due within a window, and emails the owner a reminder. For invoicing, point it at invoices past their due date and email the client rather than yourself, and ask it to log each run with a count so you can prove a reminder went out.
Two things about jobs are worth knowing before you add three of them. They are created and deleted by asking in the project chat or through SQL, not from the jobs view, which is there for reviewing, enabling and disabling. And an active job keeps the project awake, which is convenient for a billing app and less convenient for the credit line, since each run consumes backend usage like any other work.
This is the part that decides whether your app can do a month-end billing run, and it is documented in one place that competitor articles do not read.
Email sending from your own domain is a paid-plan feature. On the free plan, authentication emails fall back to the default platform sender and app emails, which is what an invoice is, do not send at all. So the honest version of "build an invoice app without code for free" is that you can build and test it for free, and the moment it has to email a client you are on a paid plan.
Above that, each paid workspace includes 50,000 transactional emails a month across the whole workspace at no extra cost, with additional emails billed at 4 credits per 1,000. That allowance is generous enough that almost no invoicing business will touch it. The limit that bites is hourly, not monthly.
| Plan | App emails per hour | Authentication emails per hour | What that means for a billing run |
|---|---|---|---|
| Pro | 100 | 500 | Around 100 invoices an hour, so a 400-invoice month end spreads over four hours |
| Business | 300 | 3,000 | A 300-invoice run clears inside the hour |
| Enterprise | 1,000 | 10,000 | Volume billing, with a request path for more |
When a workspace hits a limit, new emails are rejected until the hour resets, and the email view warns you once you have used 80 percent of a limit. If you send invoices in one batch on the first of the month, that hourly figure is the number to plan against, not the monthly one. Figures read from Lovable's documentation on 25 September 2026.
One more constraint to respect: only transactional email is supported. Invoices, receipts and payment reminders are transactional and fine. A newsletter to your client list is not, and belongs with a marketing provider.
Lovable's storage documentation uses an invoice PDF as its worked example, which saves you guessing at the right phrasing. The defaults are stricter than most people assume, and for a financial document that is exactly what you want.
The practical consequence is that "email the client a link to the PDF" needs one more sentence in the prompt than you expect. Either attach the file to the email, or ask for a sharing flow in the app that issues a link the client can use, rather than pasting a signed URL that quietly dies. Choose deliberately, because the difference is whether a client can retrieve an invoice from six months ago without asking you.
This is where a lot of invoice tutorials go wrong, so it is worth being precise. Lovable's built-in payments, through Paddle or Stripe, are designed for selling your own product: subscriptions and one-time purchases, with a hosted checkout and a customer portal. Paddle acts as merchant of record, which means it is legally the seller and it calculates, collects and remits sales tax, and issues its own invoices and receipts for those transactions.
Invoicing a named client for services you performed is a different transaction. You are the seller, the tax position is yours, and the invoice you issue is the document of record. You can absolutely put a payment link on it, and Lovable can update an invoice's status when the payment provider reports it paid, which is another prompt its own library documents. But do not assume the merchant-of-record machinery is handling your tax obligations on an invoice you raised yourself. It is handling them on products sold through its checkout.
If the payment layer is the part you care about most, the mechanics of wiring it up, the fee comparison and the go-live checks are covered in Lovable Stripe integration for a finance dashboard rather than repeated here.
Prices below were read from Lovable's pricing page, logged out, on 25 September 2026, with the credit tier dropdown opened on each card. The ladder has been stable across repeated readings this month, but it is worth checking rather than trusting any summary, including this one.
| Plan | Entry price | Credits at entry | Top of the credit ladder | Right for an invoice app when |
|---|---|---|---|---|
| Free | $0 | Daily build grants only | Not applicable | You are testing the shape and nobody needs to receive an email |
| Pro | $25 per month | 100 credits | 10,000 credits at $2,250 per month | One business billing its own clients, under 100 invoices an hour |
| Business | $50 per month | 100 credits | 10,000 credits at $4,300 per month | A team with roles, SSO and a higher email ceiling, or client work |
| Enterprise | Platform fee | Custom | Custom | Audit logs, directory sync and data residency are requirements |
Both paid ladders run eleven rungs, and the Business ladder is marked as saving up to 14 percent at the top. On top of whatever plan credits you buy, every tier gets five build credits a day, and monthly plan credits roll over for one month on a monthly plan. The build itself is the cheap part. A first working invoice app is a small number of credits; the recurring cost is the backend, which is billed as run usage, plus any scheduled jobs you leave running.
For the wider arithmetic of what it costs to turn an app like this into something you charge for, including rail fees and breakeven, see the real unit economics of selling a Lovable app. For how credits are consumed in the first place, Lovable credits explained and the Free, Pro and Business comparison cover it properly.
If the number is a text field on a form, somebody will change it. Ask explicitly for it to be issued by the system and not editable anywhere in the interface, then try to edit it.
Test it rather than assume it. Two accounts, two invoices, one attempt to open the wrong one. If it opens, the access rule is decorative.
Lovable keeps checking the authentication records it created for your email domain, and if they are changed or removed the domain goes Offline and sending stops. That usually happens when somebody tidies up DNS months later. Put it on a list somewhere.
A zero credit balance pauses the deployed app's database, storage and authentication. For a hobby project that is an inconvenience. For the thing that issues your invoices it is a bad week, so set a balance alert and treat the credit line as a utility bill rather than a top-up.
It is not one, and it does not have to be. Keep the export path open from day one so invoices and payments can leave as CSV into whatever your accountant uses. An invoice app that cannot export is a hostage situation you built yourself. If the broader debugging surface is what worries you, the common Lovable build errors and their fixes is the companion piece.
Build it yourself if you are billing your own clients, your rules are simple, and you are willing to test the access rules properly. The afternoon estimate is real for that case, and the result is genuinely yours: the code syncs to your own repository and the data exports.
Hire an Expert if the app will be client-facing under your brand, if several people need scoped access, or if the invoice numbering has to satisfy a specific jurisdiction. That is the case where the Business plan earns its price through roles, workspace controls, the higher email ceiling and the security centre, and where working with a certified Lovable Expert through the partner directory costs less than the second rebuild.
If your starting point is a spreadsheet you already bill from rather than a blank project, turning a finance spreadsheet into an app covers the import side of the same problem.
You can build one without writing code. You cannot build a good one without making engineering decisions, because numbering, access and immutability are decisions no matter who types them. The difference is that you are stating them in English instead of SQL, and the code is written and hosted for you.
Yes, from a domain you control, on a paid plan. Free plans do not send app emails at all. Plan the volume against the hourly ceiling rather than the monthly allowance.
You can add a payment link and update the invoice status when the provider confirms payment. Be clear with yourself that the built-in payments are built for selling a product through a checkout, and that the tax position on an invoice you issue to a client is yours.
The project syncs to your own repository and the database exports, so both leave with you. The wider ownership and migration picture is in the 2026 Lovable review.
An afternoon to something you can demonstrate. A second sitting for the access rules, the PDF and the email domain, and a third if the numbering has to satisfy a regulator. The demonstration is the fast part, and the fast part is not the product.
The reason to move off the spreadsheet is not that invoices look better in an app. It is that a record has rules, and a file does not enforce any of them. Lovable makes the rule-stating part cheap enough that a small business can afford to do it properly: the number nobody can type, the sent invoice nobody can edit, the client who sees one row, the PDF with an access rule of its own, and the reminder that goes out whether or not you remembered.
Build the first version this afternoon. Spend the second sitting on the four rules at the top of this article, because those are the only part an accountant will ever ask about.
TJ Alam is a certified Lovable Expert (Website Builder track) and the founder of Digi Flock Enterprises. He built tjalam.com and cyberdance.in on Lovable and works with clients on finance and data applications. The certification reflects his own assessment record and is not an endorsement by Lovable.
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.