Request Finance

• Name: Request Finance
• URL: https://www.requestfinance.com/
• Category: finance-operations platform / accounts-payable-and-payroll workflow company / Request-Network-linked payments operator
• Tags: ethereum-ecosystem
• Summary: Request Finance belongs in companies/, not projects/, because the durable dependency is a named operator packaging invoices, bills, payroll, approvals, entity accounts, and reconciliation workflow on top of Request Network and adjacent fiat/stablecoin rails. The useful question is not only what payment-request protocol exists? but which company controls the finance-operations shell teams inherit: org structure, invoice and payroll schemas, approval flow, supported rails and currencies, webhook truth, and the offchain state that decides how AP/AR work actually gets done?
• What it does:
  • Operates an all-in-one finance web application and API for companies, contractors, and DAOs to manage crypto and fiat invoices, bills, salaries, and expenses
  • Lets users issue invoices, accept crypto and fiat payments, and track invoice status without directly polling blockchains or bank accounts
  • Creates invoices and payroll objects off-chain first, then converts them into onchain Request Network requests with predefined schemas such as rnf_invoice and rnf_salary
  • Packages business-account workflow where each entity gets its own account, budget, spending limits, and approvals, which makes the company-run operating model more important than the underlying request primitive alone
  • Markets accounts-payable workflow, batch payments, audit trails, and global payout / collection support across virtual IBANs, SWIFT, ACH, SEPA, and stablecoin wallets
• Key claims:
  • The Request Finance docs say the API lets users issue invoices, accept payments in crypto and fiat, track invoice status without polling blockchains or bank accounts, and create salary payments for employees in crypto and fiat
  • The docs explicitly say The backbone of the Request Finance API is the Request Network, and describe Request Network as a decentralized protocol built on Ethereum and maintained by the Request Foundation, which is exactly why the company/application layer deserves a separate note
  • The invoices docs say invoices are created off-chain first and then converted into onchain requests, and explicitly frame invoices as an implementation of Request Network requests with a predefined schema
  • The payroll docs say payroll payments are just another invoice type using the same API surface with rnf_salary, which reinforces that Request Finance is an application-side workflow and control layer rather than a separate protocol primitive
  • The support docs describe Request as an all-in-one finance web application for companies, contractors, and DAOs to manage crypto and fiat invoices, bills, salaries, and expenses in a fast, non-custodial, and compliant way
  • The current homepage frames Request Finance as proactive spend control, says each entity gets its own account, budget, spending limits, and approvals, and markets AP workflow plus global payments in 25+ currencies and 190+ countries; these are useful operator-surface claims even where they read more like product marketing than protocol documentation
  • The current Request Network site makes the lower-layer split explicit by describing the protocol, foundation, API, dashboard, and secure payment page separately, which helps keep the protocol/application/company boundary clean
• Whitepaper: No canonical standalone company whitepaper or litepaper surfaced in this pass. The strongest primary materials were the current Request Finance homepage, support and API docs, invoice and payroll docs, and Request Network’s protocol/docs surfaces; the historical primary-source bundle remains ../whitepapers/request-finance-primary-sources-2026-04-29.md.
• Sources:
  • https://www.requestfinance.com/
  • https://support.request.finance/
  • https://docs.request.finance/
  • https://docs.request.finance/invoices
  • https://docs.request.finance/salaries
  • https://request.network/
  • https://docs.request.network/

Internal linkages

• Project-layer alias note: request-finance.
• Useful adjacent operator reads: openpayd, bridge-xyz, and aquanow.
• Cleaner contrast where the useful question becomes lower-layer payment initiation or interoperability rather than one finance-operations company shell: open-payments.

Protocol / company boundary

• Request Network is the lower-layer payment-request protocol and foundation-run public-good substrate.
• Request Finance is the company/application layer that packages offchain invoice objects, payroll objects, organization state, approvals, reconciliation, and multi-rail business workflow on top of that substrate.
• That split matters because the practical dependency for most operators is not only can a payment request exist onchain? but who runs the day-to-day finance workflow shell, defines the product defaults, and holds the offchain state teams organize around?
• That is why Request Finance belongs in companies/: the analytically important surface is the company-run AP/AR and payroll control plane, not a neutral protocol primitive.

Control surface

• Practical authority sits in organization and entity-account structure, invoice and payroll schema choices, approval flow, payment-option and currency support, audit-trail and reconciliation state, webhook truth, batch-payment workflow, and the extent to which teams build finance operations around Request-managed offchain objects before settlement lands on a chain or rail.

• The sticky dependency is operational memory: once a team’s bills, invoices, salaries, approvals, and supporting records live inside Request Finance’s workflow shell, the lock-in is to the company-run operating surface rather than to Request Network’s lower-layer request primitive alone.

• Read Request Finance as a finance-operations company first. The protocol matters, but the workflow shell is where most practical authority and switching cost accumulate.

• Last reviewed: 2026-08-06 UTC