# Payment router or invoicing software: which do you need?

Invoicing software requests and records money; a payment router divides one payment among several parties. One recipient: invoicing alone. Several: both.

---


Invoicing software and a payment router do two different jobs, so the choice is rarely one or the other: invoicing software requests money and records it, a payment router moves one incoming payment to several parties at the same moment. The criterion that settles what you need is the number of parties entitled to a share of what the client pays. With one recipient, invoicing software alone is enough. With several, the invoicing software still does its job and the router takes over the one thing it was never built for, which is dividing the money.

The two are compared as if they were alternatives because both sit near the words "get paid". An invoicing or accounting tool creates the invoice, applies the tax, chases the client and tells you what is still owed; its "pay now" button brings the money to one account, yours. A payment router produces no invoice and keeps no books. It sends each agreed share of the client's payment to the party it belongs to, without one of them receiving the whole sum first.

This article compares the two families on the same criteria, then works one engagement shared by three parties through each setup, with the number of invoices, the number of payments and who holds the money at each stage. Invoice rules and tax treatment vary by country; what follows is general information, not legal or tax advice.

<figure class="keyfacts">
<div class="keyfacts-grid">
<div><b>3 to 1</b><span>payments needed in the worked example, without and with a router, for the same three parties</span></div>
<div><b>$12,000</b><span>belonging to other parties sits in one party's account when that party collects the whole amount</span></div>
<div><b>3 invoices</b><span>are issued in every version of the example: a router changes the payments, not the paperwork</span></div>
</div>
<p class="fig-src">Worked example of this article: one engagement shared 60 / 25 / 15 among a lead firm, a specialist and an introducer. The amounts are illustrative.</p>
</figure>

## What does invoicing software do?

Invoicing software creates the document that asks for payment and keeps the record of what is owed, what was paid and what tax applies. Its output is paperwork and accounting data: a numbered invoice, a ledger of receivables, reminders, and entries that feed the accounts.

The family runs from a standalone invoicing tool to the invoicing module of a full accounting package. What they share is a set of functions built around the document:

- **Creating and numbering.** Each invoice gets a unique number in sequence, the seller's and the buyer's details, a description of the work, dates and amounts.
- **Applying tax.** The tool holds the rates you configure and computes the tax line per item, then the total. It keeps the tax collected separate from your revenue so that a return can be prepared from it.
- **Sending and chasing.** The invoice goes out by email or as an electronic invoice, and the tool sends reminders before and after the due date on a schedule you set.
- **Tracking what is owed.** Every invoice has a status: draft, sent, viewed, part paid, paid, overdue. An accounts receivable ageing report sorts unpaid invoices by how late they are, typically in bands of 1 to 30 days, 31 to 60 days, 61 to 90 days and 91 days or more.
- **Recurring billing.** A retainer or a subscription is invoiced automatically each period, and many tools can also collect it automatically from a stored card or a bank mandate.
- **Feeding the books.** A paid invoice becomes revenue, tax payable and a bank entry. In an accounting package, the bank feed is matched against open invoices so that the ledger and the bank statement agree.

The "pay now" button is the source of the confusion with a router. It does not make the invoicing tool a payment system. It connects the invoice to a card processor or to a bank payment method that the business has signed up for separately or through the tool. The client pays by card or bank transfer, the processor or the bank moves the money, and the invoicing tool is told that the invoice is settled. One invoice, one payer, one account credited.

## What does a payment router do?

A payment router divides one incoming payment among several agreed recipients at the moment it is paid. Its output is money in several places at once and a record of who received what; it produces no invoice, no tax line and no reminder.

The mechanism has three parts. First, the parties agree how the amount is shared before any money moves: each recipient has a stated share and a stated destination. Second, the client pays once, the total. Third, the payment is divided as it arrives, so that each recipient receives its share directly. No recipient is paid by another recipient, and no party receives the full amount with an obligation to pass part of it on.

Other families of tools also divide money, notably the split features some card processors offer to platforms. That is a different comparison. The routing column of the tables below describes an onchain payment router, where the client's single payment and the recipients' shares are one transaction.

## How do the two compare on the same criteria?

On the same criteria, invoicing software and a payment router barely overlap: the first produces documents and records and relies on another service to move money to one account, the second moves money to several accounts and produces only a payment record. The two tables set the families side by side, first on the money, then on the paperwork.

| Criterion | Invoicing software | An onchain payment router |
| --- | --- | --- |
| What it produces | A numbered invoice, reminders, receivables and accounting entries | A divided payment and a record of who was paid what |
| What it moves | Nothing itself; a linked card processor or bank payment moves the money | The client's payment, from the client to each recipient |
| Who holds the money | The processor or bank during settlement, then the one business that invoiced | Nobody in between: it routes and does not hold |
| Recipients one payment can reach | One: the account of the business that issued the invoice | Several, each with its own share, within the router's limit |
| What happens after the client pays | The invoice is marked paid; any sharing with others is a separate step, done by the business | Every recipient has its share at once; nothing is left to distribute |
| What the client sees | An invoice with a due date and a payment button or bank details | A payment request for the total; one payment to make |

The second table covers what surrounds the payment.

| Criterion | Invoicing software | An onchain payment router |
| --- | --- | --- |
| Tax functions | Rates per item, tax lines, totals, tax reports | None |
| Accounting functions | Receivables, ageing, bank matching, revenue and expense entries | None; its record is an input for the books |
| Reminders and collections | Scheduled reminders, overdue status, statements, sometimes late-fee lines | None; it acts only when the client pays |
| Recurring billing | Yes, with automatic collection in many tools | Not its purpose: it handles a payment for an agreed deal |
| Record that exists afterwards | The invoice, its payment status and the ledger entries, kept by the business | The payment itself, onchain, visible to every party |

Read by column, the tables show opposite shapes. Invoicing software is broad and continuous: it runs all year, across every client. A router is narrow and momentary: it does one thing, at the moment of payment, for the parties of one deal.

## What does invoicing software do that a payment router does not?

Invoicing software produces a legally adequate invoice, computes tax, chases payment, ages receivables and keeps the books; a payment router does none of these. A business that adopts a router still needs every one of those functions, from the same tool it used before.

**A compliant invoice.** Most countries prescribe what an invoice must contain, and the list changes from one country to the next. Two official examples show the pattern. In the United Kingdom, government guidance says an invoice must include a unique identification number, the business's name, address and contact information, the customer's name and address, a clear description of what is charged for, the supply date, the invoice date, the amounts charged, the VAT amount if applicable and the total owed. In the European Union, Article 226 of the VAT Directive lists the details a VAT invoice must carry, among them the date of issue, a sequential number, the supplier's VAT identification number, the names and addresses of supplier and customer, the nature of the goods or services, the taxable amount, the VAT rate and the VAT payable, and each member state applies those rules through its own law. A payment record contains none of this by design. It shows an amount, a date and the recipients.

**Deadlines and retention.** The duties do not stop at content. According to HMRC's VAT record-keeping notice, a VAT-registered business in the United Kingdom must normally issue a VAT invoice within 30 days of the supply and must generally keep its VAT records for at least 6 years. Other countries set their own periods. Invoicing software is where those documents are issued on time and stored.

**Tax lines.** The invoicing tool applies the rule you or your accountant configured. A router divides whatever total it is given and has no notion of which part of that total is tax.

**Reminders and ageing.** A router acts when the client pays. Before that moment it has nothing to do. The work of getting to that moment, the reminders, the month-end statement and the ageing report, belongs to invoicing software.

**The books.** Revenue recognition, expenses, tax payable, bank reconciliation and year-end reports come from the accounting side. A routed payment is one event that the books have to record; it is not a set of books.

## What does a payment router do that invoicing software does not?

A payment router pays several recipients from one client payment, fixes each share before the money moves, and leaves no party holding another party's share. Invoicing software can describe a shared deal on paper, but the money it helps collect always lands in one account.

**Several recipients paid at once.** An invoice has one issuer, and its payment button credits that issuer. A router credits every recipient of a shared deal from one payment by the client.

**Nobody holds the others' shares.** In the collect-and-pass-on route, the collecting party's bank account contains money that belongs to others, for a few hours or a few weeks. The other parties depend on that firm's diligence, its cash position and its payment run. Nothing is wrong with the arrangement, and most subcontracting works this way; with routing, the waiting period simply does not exist.

**Shares agreed beforehand.** A split written into a spreadsheet after the client has paid is one party's calculation. A split recorded before payment, with each recipient's share and destination fixed, is an agreement the payment then executes.

**A common record.** Each party's invoicing software shows that party's own side: the lead firm sees its invoice paid, the specialist sees its own. A routed payment is a single record that shows all the shares together, so each recipient can verify its own amount and that the others were paid, without asking anyone for a statement.

## How do invoicing software and a payment router work together?

Invoicing software and a payment router work together in sequence: the invoice states the amount due and how to pay it, the router carries out the payment and divides it, and the payment record goes back into each party's books.

<figure class="fig">
<figcaption><b>One shared deal through both tools</b><span>Four stages, from the agreement to the books</span></figcaption>
<ol class="steps">
<li><b>Agree the shares</b>Before any invoice goes out, the parties settle who receives what, as percentages of the amount the client will pay, and record that split in the router. The engagement letter or subcontract says the same thing in words.</li>
<li><b>Issue the invoice</b>The invoicing software produces the invoice as usual: number, parties, description, tax if any, total and due date. Where bank details or a card button would normally appear, the invoice gives the router's payment request as the way to pay.</li>
<li><b>The client pays once</b>The client pays the invoiced total through the router. Each recipient receives its share at that moment. Until the client pays, the invoicing software keeps doing its work: reminders, overdue status, ageing.</li>
<li><b>Record the payment</b>Each party marks its invoice paid in its own invoicing software, with the payment record as evidence, and books its own share according to its own rules.</li>
</ol>
</figure>

Two questions come up at the last stage, and both belong to your accountant rather than to either tool.

The first is who invoices whom. Dividing the money at the moment of payment does not decide who supplied what to whom; the contracts do. Two arrangements are common. In one, the lead firm contracts with the client for the whole engagement and invoices the full amount, and the other parties invoice the lead firm for their shares. The routed payment then settles all of those invoices at once: the client invoice, and the two invoices addressed to the lead firm. In the other, each party invoices the client for its own share, and the single routed payment settles each of those invoices. Which arrangement applies, and what tax follows from it, depends on the contracts and the country.

The second is reconciliation. An accounting package expects the bank entry to match the invoice. A lead firm that invoiced the full amount and received only its own share will see an entry smaller than its invoice. The difference is not a shortfall: it was paid directly to the firm's subcontractors and settles what the firm owed them. Accountants usually record this kind of settlement through a clearing account or a manual payment entry, so that the client invoice shows as fully paid and the subcontractor invoices show as settled. Agree the entry with whoever keeps your books before the first routed payment.

## What does a $30,000 engagement shared by three parties look like in each setup?

On a $30,000 engagement shared by three parties, invoicing software alone requires three payments and either one party holding $12,000 for the others or the client paying three invoices; adding a router brings it down to one payment with nobody holding another party's share. The number of invoices is three in every case.

The assumptions of this worked example, which is illustrative: a client engages a lead consultancy for a project priced at $30,000. A specialist does part of the work and an introducer brought the client. The agreed shares are 60% for the lead consultancy, 25% for the specialist and 15% for the introducer, which gives $18,000, $7,500 and $4,500, for $30,000 in total. Tax is left out because it depends on the country and on each party's status.

With invoicing software alone, the parties choose between two routes. In the first, the lead consultancy invoices the client for $30,000, receives it, then pays $7,500 and $4,500 against the invoices the two others send it. In the second, each party sends the client its own invoice.

| Item | Invoicing alone, lead collects | Invoicing alone, each bills the client | Invoicing software and a router |
| --- | --- | --- | --- |
| Invoices issued | 3: one to the client, two to the lead | 3: all to the client | 3: either pattern |
| Payments the client makes | 1 of $30,000 | 3: $18,000, $7,500 and $4,500 | 1 of $30,000 |
| Payments in total | 3 | 3 | 1 |
| Held for others | $12,000, by the lead | $0 | $0 |
| Lead consultancy receives | $30,000, keeps $18,000 | $18,000 | $18,000 |
| Specialist receives | $7,500, when the lead pays | $7,500, when the client pays that invoice | $7,500, when the client pays |
| Introducer receives | $4,500, when the lead pays | $4,500, when the client pays that invoice | $4,500, when the client pays |
| **Total received** | **$30,000** | **$30,000** | **$30,000** |

Each route has a cost that the table makes visible. When the lead collects, 40% of what arrives in its account, $12,000 of $30,000, is not its money, and the specialist and the introducer are paid on the lead's timetable. When each party bills the client, nobody holds anything for anyone, but the client has three invoices to approve, three payees to set up and three payments to make, and each can be paid on a different day or not at all.

With both tools, the client's experience is that of the first route, one total to pay, and the recipients' position is better than in the second, because the three amounts cannot arrive on different days. The router changes the payment rows only. The invoice row does not move.

## When is invoicing software alone enough?

Invoicing software alone is enough whenever the money the client pays belongs to one recipient: your business. A router has nothing to divide in that case, and adding one would add a step without a purpose.

The situations where invoicing software alone is the right setup are the majority of business billing:

- **One recipient.** You did the work, you invoice, you are paid. Any staff or suppliers you pay afterwards are your own costs, paid from your own money on your own schedule.
- **Card or bank payment preferred by the client.** The payment methods invoicing software already connects to serve a client whose purchasing runs on cards, bank transfers or purchase orders.
- **Recurring billing.** A monthly retainer or a subscription collected automatically from a stored card or a bank mandate is what the recurring function of invoicing software exists for. A router handles a payment for an agreed deal and has no billing cycle.
- **Sharing that is genuinely your own cost.** If you pay a subcontractor a fixed fee whether or not the client pays you, the subcontractor is your supplier, not a party to the client's payment. That is accounts payable, which accounting software handles.

The test is the same in every case: once the client has paid, does anyone other than you have a claim on a part of that payment? If not, invoicing software covers the whole job.

## Why is a payment router alone not enough?

A payment router alone is not enough because moving money correctly does not create the document that justified the payment or the accounting record of it. A business that routes payments without invoicing has been paid, and has nothing to show its tax authority, its accountant or its client's accounts department.

The client's accounts payable team needs an invoice to support the payment: it does not release $30,000 against a payment request with no document behind it. Your books need the same invoice to record revenue and any tax due, and the rules on content, issue and retention described earlier apply whatever the payment method.

<aside class="callout">
<span class="callout-label">Before you rely on a payment record</span>
<h4>A payment record is not an invoice</h4>
<p>A routed payment proves that money moved and to whom. It carries no invoice number, no description of the supply and no tax line. Each party still issues or receives the invoice its own country's rules require, and keeps it for the period those rules set.</p>
</aside>

The same holds for each recipient. The specialist and the introducer of the worked example have their own books and, in many countries, their own duty to invoice somebody for the $7,500 and the $4,500. Receiving the money directly changes when it arrives, not that duty.

## Where does an onchain payment router such as Shaka fit?

An onchain payment router fits the deal where one client payment belongs to several parties who want to be paid at the same moment, alongside whatever invoicing software each of them already uses. It replaces the collect-and-pass-on step, not the invoice.

Shaka is one such router. Each party's share is set as a percentage of the deal, and each recipient can sign their share before the client pays, which costs the parties nothing. The client pays once, through a payment link, and every party is paid their share at the same moment, in one transaction. Shaka routes the payment and never holds the funds. Destinations are fixed and signed before the payment, so the money cannot be redirected at the last minute. The payment is onchain and final, every party can see that the others were paid, and a payment record can be kept for the file, which is the document each party attaches to its invoice when marking it paid.

Where it does not fit is as plain. Shaka issues no invoice, computes no tax, sends no reminder and keeps no books, so it works next to invoicing software and never instead of it. A deal has at most 20 recipients. It has no place where every payment belongs to one recipient, in recurring billing, or with a client who can only pay by card or bank transfer: the payment is onchain, and the client and every recipient must be able to pay and receive that way. It is not an escrow service, a payroll tool, a bank or a card processor.

## How do you choose between one tool, the other or both?

The choice depends on two things: whether anyone besides you is entitled to a part of the client's payment, and whether the client and the parties can use the router's payment method. Almost every business needs invoicing software; a router is added for the deals that are shared.

| Your situation | What you need | Why |
| --- | --- | --- |
| You bill clients and keep the whole payment | Invoicing software | One recipient: nothing to divide |
| You bill a retainer or subscription each month | Invoicing software with recurring collection | A billing cycle and stored payment methods are invoicing functions |
| You collect for a shared deal and are comfortable paying the others afterwards | Invoicing software, and a clear written split | Collect-and-pass-on works when the parties trust the timetable |
| Several parties share one payment and want to be paid at the same moment | Invoicing software and a payment router | The invoice requests and records; the router divides |
| You are a minor party in someone else's deal and fear waiting for your share | Ask for the payment to be routed; keep invoicing as usual | Your share then arrives when the client pays, not when the lead pays |
| The client can pay only by card or bank transfer | Invoicing software; split by another method | An onchain router needs a client who can pay onchain |

One check helps before you decide. Look at the last ten payments you received and count those where part of the money left again for a party named in the deal. If the answer is none, you have no routing need. If those pass-on payments were sometimes late or disputed, that is the step a router removes.

Whatever the answer, the invoice stays. The decision is only about what happens in the seconds after the client pays it.