Inside Ledger365 Invoicing

Invoicing is the commodity feature of accounting SaaS. Every tool does it. Most do it badly enough that you only notice when something breaks — a tax rate changes and old invoices recalculate, a client disputes a charge and you cannot prove what was sent when, a recurring template scales to a hundred clients and you discover the system was treating each one as a separate one-off.

These are not user-experience problems. They are architecture problems. They surface as user-experience problems six months after you have committed to the platform — when the cost of switching is highest and the willingness to switch is lowest. By design or by neglect, the architecture you can never see is the architecture you live with.

What follows is a tour of eight architectural decisions that shape how Ledger365 invoicing works. Some are user-facing features. Some are decisions about where data lives, what gets frozen, what gets referenced. All of them earn their keep when the work gets serious.

The architecture you can never see is the architecture you live with. The best test of an invoicing system is the one your accountant performs a year in, not the demo you ran in week one.

01The foundation — an invoice is not a ledger entry

This is the most consequential decision in the whole system, and the easiest to miss.

In Ledger365, an invoice is a commercial document. It records what one party billed another party, when, for what, and at what rate. It lives in its own table with its own audit trail. It does not touch the general ledger.

The ledger is touched only by Transactions — separate records that account for the money side of what happened. When an invoice is paid, a Transaction is recorded against the appropriate accounts (cash, accounts receivable, revenue, tax payable) following standard double-entry rules with direction determined by each account's natural side. The invoice is referenced; it is not the ledger entry.

This separation sounds academic. Its consequences are practical:

• Invoices can be edited or voided without rewriting the books. The GL stays whole. The audit trail remains.
• Reporting from the ledger is clean. Revenue is recognised from transactions, not from documents that might still be drafts, voided, or under dispute.
• Tax recognition follows cash or accrual rules cleanly because tax is recorded on the transaction side, not implicitly on the document side.

Most SMB invoicing tools collapse these two ideas — invoice and ledger entry become the same record. When that happens, every invoice operation is a ledger operation, and you cannot meaningfully edit an invoice without distorting the books. The illusion of simplicity has a real cost.

02Multi-tier tax resolution

Tax is the place where most invoicing systems quietly fall apart.

The single-rate model — one tax rate per line — works until it doesn't. The moment you sell a product that ships across jurisdictions, or that has different tax classifications for different customer types, or that's bundled with services taxed at a different rate, the single-rate field stops being enough.

Ledger365 resolves tax through three layers, in order of precedence. Closer to the invoice always wins:

• Invoice — the invoice itself can override tax for all its lines. Useful for export-exempt invoices, B2B reverse-charge invoices, or charity invoices.
• Template — invoice templates carry their own tax settings. Useful for recurring billing patterns where the tax handling is consistent across many invoices.
• Product — products carry default tax through their Tax Group. This is the fallback for everything else.

When an invoice line is saved, the system walks this hierarchy and resolves the applicable tax. The rule is explicit and predictable, not buried in invisible logic.

This is what allows a single product catalogue to serve multiple sales contexts — domestic, export, intercompany, exempt — without forcing duplicate product records for each tax variant. The product is the product. The tax depends on the context the product is being sold into.

03Tax is preserved at save time, not at read time

The companion decision to multi-tier resolution, and the one that protects you from the most common silent bug in accounting software.

When an invoice line is saved, Ledger365 stores the resolved tax rate, the resolved tax amount, and a TaxSource field that records which layer the tax came from — Invoice, Template, or Product. The invoice line becomes a frozen statement of what was charged and why.

What this prevents is the historical recalculation problem. If your jurisdiction raises VAT from 19% to 20% on the first of March, every invoice issued before March stays at 19%. The system does not reach back and "correct" historical invoices to match the current rate. It does not need to — the rate that applied at the time, and the level it was resolved from, is stored on the line itself.

This is how invoices are supposed to behave. It is not how all invoicing software behaves. The number of systems that quietly recalculate historical totals when a tax rate changes is a category of bug that mostly goes unreported, because the people affected only discover it when their accountant flags a discrepancy and traces it back six months.

04Invoice templates as first-class entities

In most SMB tools, "templates" means a default header layout or a saved set of line items. The template is essentially a copy-paste convenience. When you generate an invoice from one, the system copies the values onto the invoice and forgets the template existed.

In Ledger365, an Invoice Template is a real entity with its own table, its own lifecycle, and its own tax configuration. A template carries:

• A line item structure — products, default quantities, default rates
• A tax configuration that occupies the middle tier of the three-level resolution
• Recipient defaults — default party, payment terms, attachments
• Its own audit log

An invoice generated from a template carries a reference back to the template. Changes to the template propagate to future invoices generated against it. Past invoices remain locked at their save-time values, because of the previous decision about tax preservation.

This matters when you scale recurring billing. Updating a price on the template updates it for all future invoices using it. Past invoices stay accurate. There is one source of truth for the configuration, and no broken history. The pattern is what makes recurring billing actually work at scale — rather than working until the moment you change something and discover that "templates" never really meant what you thought they meant.

05Estimates have their own lifecycle

Most tools treat estimates as draft invoices — same table, different status field. This is convenient and architecturally wrong.

Estimates and invoices have genuinely different lifecycles. An estimate can be sent, revised, expired, accepted, rejected, or converted. An invoice can be sent, paid, partially paid, disputed, voided, or written off. The state machines are different. The reporting requirements are different. The party-facing view is different.

In Ledger365, Estimates live in their own table with their own lifecycle. An accepted estimate can be converted to an invoice, at which point a real invoice record is created with proper audit trail, and the estimate is marked converted. The two records remain linked but distinct.

The benefit is reporting that actually makes sense. A pipeline report on estimates does not accidentally count invoices. An AR Aging report on invoices does not include unsent estimates pretending to be drafts. The numbers stay clean because the data model stays honest.

06A full audit log on every operation

Every meaningful invoice operation — create, edit, send, void, mark-paid, attach, comment — is logged. The log records who, what, when, and where applicable the before-and-after values.

This is the feature you do not notice for two years, and then suddenly need on a Tuesday afternoon when a client disputes a charge and you need to demonstrate exactly what was sent and when. Or when an auditor asks for the change history on a specific document. Or when a sales rep claims they "never edited that figure" and the log calmly disagrees.

Audit logging is also where compliance lives. Regulations across most jurisdictions require demonstrable record-keeping for invoiced amounts. "Demonstrable" is doing a lot of work in that sentence. The audit log is what makes the word mean something concrete.

The audit log is the feature you do not notice for two years, and then suddenly need on a Tuesday afternoon.

07Bring your own SMTP, and we log the delivery

When Ledger365 sends an invoice email, two things happen that most SMB invoicing tools do not do.

First, the email goes through SMTP credentials configured by your company. Your sales@yourbusiness.com address sends to the client, not noreply@invoicingplatform.com. The client sees your brand and your address. Your deliverability and sender reputation are yours, not borrowed from a shared platform pool that you do not control and cannot improve.

Second, the system logs the send against the invoice record — recipient address, timestamp, message ID, status. If a client says "I never received the invoice," the answer is not a guess. The send log shows what was attempted, when, and to which address. If the message bounced, the bounce is recorded. If it delivered, the delivery confirmation is recorded.

These are small features individually. Together they shift the platform from "the tool you used to send the invoice" to "the system of record for the commercial communication." The distinction matters when a dispute happens, when an auditor asks, or when a sales conversation hinges on "did they get our last quote." A guess is not enough. A log is.

08A real client portal, not just an invoice link

Ledger365's Client Portal is a separate access surface with its own role and permission model. A party — your customer — logged into the portal sees:

• Their own invoices, with current status and payment history
• Their statements — open balances, aged receivables relevant to them
• Their estimates pending acceptance, with the option to accept or reject in place
• Their attachments and supporting documents

What they do not see is the rest of your business. The portal access is bounded — read-only by default, scoped to the party, with no leakage into other parties' data or your internal records.

This sounds obvious in description. The alternative — the most common implementation across SMB tools — is a magic link to a single invoice page. Useful for one-off payment, but not a portal. It does not let the customer see their own history, accept estimates, download statements, or self-serve any question they might want to ask before reaching for the phone.

The Ledger365 portal lets your clients self-serve everything that concerns them, and only what concerns them. The boundary is enforced by the role model, not by hoping the URL stays secret.

What ties it all together

Re-read the list and a pattern emerges. None of these features are unique on their own. Multi-tier tax resolution exists in enterprise tools. Audit logging exists in compliance-grade systems. Templates as first-class entities exist in NetSuite. Bring-your-own-SMTP exists in custom enterprise implementations. Client portals with proper role boundaries exist where someone bothered to build them.

What is uncommon is finding them together, at the SMB tier, in one cohesive system. The argument Ledger365 makes is that a growing business should not have to choose between "easy" — FreshBooks, Wave, the entry-tier QuickBooks Online plans — and "complete" — NetSuite, Sage Intacct. The middle is buildable. We built it.

If you want to verify the architecture rather than take our word for it, the right test is the one your accountant will perform after a year of use. Pull a profit-and-loss for last year. Change a tax rate or void a historical invoice. Pull the same profit-and-loss again. The numbers should match. In a system built correctly, they will. In a system that conflates the invoice with the ledger entry, they will not.

That test alone is what most of these eight decisions are quietly defending.