---
title: "Request Finance (invoicing, payroll & payables)"
url: "https://caper.network/wiki/dao-governance/tooling/treasury/request-finance"
updated: 2026-09-14
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Request Finance (invoicing, payroll & payables)

|  |  |
| --- | --- |
| **Tool** | [Request Finance](https://www.requestfinance.com/) — the commercial app; [Request Network](https://request.network/) is the protocol under it |
| **Category** | Accounts payable & receivable · contributor payroll · expenses · accounting export |
| **Founded** | 2017 — [Y Combinator W17](https://www.ycombinator.com/companies/request-network), Christophe Lassuyt (CFO) and Etienne Tatur (CTO) |
| **Protocol** | Open-source, non-custodial; [MIT-licensed monorepo](https://github.com/RequestNetwork/requestNetwork), request data on Ethereum + IPFS |
| **Protocol pricing** | 0.9 % flat fee per transaction, capped at $500 per payment ([read 14 September 2026](https://request.network/)) |
| **Networks** | Ethereum, BNB Chain, Base, Polygon, Arbitrum, Optimism and Tron, plus bank rails (ACH, SEPA, SWIFT, Faster Payments) |
| **Known DAO users** | The Sandbox, [Aave](/wiki/daos/lending/aave-dao), [MakerDAO](/wiki/daos/stablecoins/sky-dao) ([2021 reporting](https://crypto.news/sandbox-aave-ico-request-invoicing-crypto-fiat-invoicing-payroll/)) |
| **Sits beside** | [Safe](/wiki/dao-governance/tooling/treasury/safe) for custody · [Sablier](/wiki/dao-governance/tooling/treasury/sablier) / [Superfluid](/wiki/dao-governance/tooling/treasury/superfluid) for streams |

**Request Finance** is the invoicing and payables layer of a DAO treasury: the place where a contributor's claim on the treasury becomes a document — an invoice, an expense, a payroll run — that somebody approves before any money moves. It sits above the multisig rather than replacing it. Custody stays in the [Safe](/wiki/dao-governance/tooling/treasury/safe); what Request Finance adds is the paperwork, the approval trail, and the export that turns a wall of token transfers into something an accountant can read.

That is a real gap. A DAO can vote a budget on-chain and hold it in a multisig, but [paying the people who do the work](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) still means collecting invoices, checking them, converting some of them to fiat, and reconciling the lot at the end of the quarter. Most DAO tooling addresses the authorization problem. Very little of it addresses the bookkeeping.

## Two things with one name

Request splits into a protocol and a business built on it, and the distinction matters when you are assessing how much of the stack you actually depend on.

[Request Network](https://request.network/) is the protocol: an open-source, non-custodial payment-request standard where, in its own words, funds are never held. Its [TypeScript monorepo](https://github.com/RequestNetwork/requestNetwork) is MIT-licensed, and request data is stored on Ethereum and [IPFS](https://ipfs.tech/) (with a [TheGraph](https://thegraph.com/) indexing path as an alternative), so an invoice is a shared on-chain artifact rather than a row in one vendor's database. The network reaches the major EVM chains — Ethereum, BNB Chain, Base, Polygon, Arbitrum, Optimism — and Tron, and the foundation describes the contracts and SDK as public goods that integrators can keep operating regardless of what happens to the foundation itself.

[Request Finance](https://www.requestfinance.com/) is the product: a business account with corporate cards, accounts payable, accrual accounting, and stablecoin-plus-bank settlement, sold to finance teams. Its [developer documentation](https://docs.request.finance/) describes it as an accounts-payable and receivable API sitting on Request Network, so an integrator can issue invoices and track their status without querying a chain directly. Its front page still reports **1,500+ finance teams** and **$1B+ processed**, unchanged when re-read on 14 September 2026.

That split is no longer as clean as it was. Read on **14 September 2026**, [request.network](https://request.network/) fronts a priced commercial service — **0.9 % flat fee per transaction, capped at $500 per payment**, and a claimed 95 % stablecoin-supply coverage, though the **$2B+ volume processed** figure it carried on 26 August 2026 is no longer on the page — and the [protocol documentation](https://docs.request.network/) now describes three products, a Dashboard, a Secure Payment Page and an API, benchmarked against “Stripe, PayPal & crypto payment tools.” The contracts and SDK remain MIT-licensed and non-custodial, so the escape hatch is real; but a DAO reading “protocol” and picturing a neutral standard should note that both halves of the name are now sold as products, and only the repository is a public good.

## How a DAO actually uses it

The working pattern is unglamorous and it is the point:

- **Contributors invoice the DAO.** Each contributor or vendor issues an invoice denominated in a stablecoin or token, which becomes a request on the protocol rather than a PDF in someone's inbox.
- **An approver clears the queue.** Operations staff review and approve bills, which is where budget discipline actually lands — long after the [proposal](/wiki/dao-governance/concepts/voting/proposal-lifecycle) that authorized the budget in the first place.
- **The multisig pays in a batch.** Approved bills are paid from the connected wallet — [Safe](/wiki/dao-governance/tooling/treasury/safe), MetaMask or Ledger are the [listed integrations](https://www.requestfinance.com/) — so signers approve one transaction covering many invoices instead of signing each transfer by hand.
- **Accounting exports out.** Xero, QuickBooks and SAP integrations carry the result into ordinary books, and bank rails (ACH, Wire, SEPA, SWIFT, SPEI, Faster Payments) cover the contributors who need fiat.

Nothing here changes who controls the money. The signers on the Safe still control it. What changes is that the DAO can answer “what did we pay, to whom, for what, and under which budget” without an archaeologist.

## Adoption

Request Invoicing found its first real market among DAOs and token-treasury companies, precisely because they had money and no back office. By [November 2021](https://crypto.news/sandbox-aave-ico-request-invoicing-crypto-fiat-invoicing-payroll/), reporting named The Sandbox, [Aave](/wiki/daos/lending/aave-dao), [MakerDAO](/wiki/daos/stablecoins/sky-dao) and Chainstack among its users, with roughly $144M in crypto invoices processed across 900+ corporate clients — The Sandbox's COO put the saving at a 90% reduction in monthly payment time. Support then spanned 40+ digital currencies, 9+ fiat currencies and 10+ chains.

The trajectory since is worth reading honestly. The company's own marketing now leads with enterprise stablecoin payments and CFO tooling — corporate cards, accrual accounting, bank rails — not with DAO payables. That is the same drift seen elsewhere in [DAO tooling](/wiki/dao-governance/tooling/dao-tooling-overview): the crypto-native niche proves the product, and then the addressable market pulls it toward companies with a CFO. A DAO evaluating it today is buying enterprise finance software that happens to settle on-chain, rather than a DAO-first tool.

## Where it sits in the stack

Treasury tooling divides by the question it answers, and Request Finance answers only one of them.

- **Custody** — [Safe](/wiki/dao-governance/tooling/treasury/safe) and [Squads](/wiki/dao-governance/tooling/treasury/squads) hold the assets and decide who can move them.
- **Asset management** — [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) and [Enzyme](/wiki/dao-governance/tooling/treasury/enzyme) decide what the assets do while they sit there.
- **Continuous pay** — [Sablier](/wiki/dao-governance/tooling/treasury/sablier) and [Superfluid](/wiki/dao-governance/tooling/treasury/superfluid) stream salaries and vesting by the second, replacing the invoice entirely for recurring roles.
- **Allocation** — [Coordinape](/wiki/dao-governance/tooling/treasury/coordinape) decides who deserves what, before anyone bills for it.
- **Payables and books** — Request Finance, for the one-off, the vendor, the contractor and the tax authority.

A mature [treasury operation](/wiki/dao-governance/concepts/treasury/dao-treasury-management) usually runs several of these at once: streams for core contributors, invoices for everyone else, and a multisig underneath all of it.

## Limits

The honest caveats are structural rather than incidental.

- **The record of obligation is off-chain.** The payment settles on-chain, but the approval workflow, the budget, and the audit trail live in a hosted application. If the vendor disappears, the transfers survive and the institutional memory of why they happened may not — though the protocol's public-goods contracts and MIT SDK give an integrator a path to keep operating. That path is worth checking rather than assuming, and re-read on **14 September 2026** it holds: the [monorepo](https://github.com/RequestNetwork/requestNetwork) is unarchived and was last pushed on 4 September 2026, sits among 62 repositories in the organisation, and its most recent smart-contract work — [a recurring-payment contract deployment](https://github.com/RequestNetwork/requestNetwork/pull/1767) — merged on 31 August 2026. A dependency that survives its vendor has to still be maintained by someone; here it is.
- **Fiat means KYC.** The bank rails that make the product useful come with identity requirements a pseudonymous DAO may not want to meet, which pushes the DAO toward a [legal wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures) to sign for them.
- **It does not constrain spending.** Approval workflows are a control only if the signers respect them; nothing in the tool stops a multisig from paying an unapproved address directly. The enforcement, if you want any, has to live in the treasury contract itself.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no invoicing layer, and a caper paying real-world contractors would still need one — the bookkeeping problem does not vanish because the ledger is public. What a caper moves on-chain is the authorization, not the paperwork.

Treasury money leaves a caper only through a payout proposal, and the recipient account, the currency and the amount are frozen into the option members actually voted on. Execution reads that stored recipient rather than accepting one from whoever submits the transaction, so the person who triggers the payment cannot redirect it, and the step is once-only. The transfer is delivered through an account locker, so a recipient's deposit rules cannot strand it, and it emits a transfer event against the treasury's opening and closing balance.

Which is to say the control Request Finance implements as an approval workflow, a caper implements as the shape of the proposal: there is no separate approval stage to bypass, because the vote and the payment instruction are the same object. Everything a finance team would call reconciliation — invoices, expense categories, statutory books — stays outside, where a tool like Request Finance is still the right answer.

## References

- Pricing, volume and product-line figures on this page were read from the vendor’s own sites and repository on 26 August 2026 and re-read on 14 September 2026.
- Request Network, [protocol site](https://request.network/) · [protocol documentation](https://docs.request.network/) · [RequestNetwork/requestNetwork (MIT)](https://github.com/RequestNetwork/requestNetwork)
- Request Finance, [product site](https://www.requestfinance.com/) · [AP/AR API documentation](https://docs.request.finance/)
- Y Combinator, [Request Network company profile (W17)](https://www.ycombinator.com/companies/request-network)
- crypto.news, [“The Sandbox, AAVE & major ICOs all use Request Invoicing”](https://crypto.news/sandbox-aave-ico-request-invoicing-crypto-fiat-invoicing-payroll/) (23 Nov 2021)