Build accounts receivable

With an accounts receivable (AR) program, your customers collect money from the people who owe them, inside your product. You take in checks and bank transfers, match each one to an invoice, take your fee, and send the balance to your customer's bank. This tutorial shows how to build that on Unit and points to the API reference for each step.

What You Will Build

Throughout the tutorial we use a running example. Property Hero is a software company that serves 10,000 property managers. Its property managers collect rent and fees from the buildings and tenants they serve through physical checks, lockboxes, and bank transfers. They want all of it to land in their own bank account, at JPMorgan or wherever they already bank.

Here is one month's collection run. Property Manager 1 collects three $1,010 payments. One is a check they deposit, one is a check mailed to a lockbox, and one is an ACH debit pulled from a tenant's bank. All three land in the property manager's wallet. Property Hero charges $30 in fees, which land in its revenue account, then pushes the remaining $3,000 to the property manager's Chase account. The wallet ends the month back at $0.

How to read the diagram:

The boxes are accounts and the parties around them. The colored outline around each box shows its type, as in the key at the bottom.

• The orange box is Property Manager 1's wallet account (FBO). Every receivable lands here. It's a pass-through account with its own routing and account numbers, and its balance usually returns to $0 after payout. The faded orange boxes below it are the wallets of Property Managers 2 and 3, set up the same way.
• The green box is Property Hero's revenue deposit account. The month's $30 in fees lands here.
• Gray boxes are the outside parties. Customers 1 to 3 are the payers (tenants and buildings). The Property Manager 1 (Chase) box is the property manager's own bank account, linked through Plaid.
• Arrows are payments. Gray labels such as "invoice_id" = "114" are tags that tie each payment back to your own system.

Primitives You Will Use

Primitive	Role in an AR program	Reference
Customers	Your company and each business you serve, onboarded through an application	Customers
Wallet accounts (FBO)	A collection account for each customer, which receives payments and pays them out	Wallets
Counterparties	External bank accounts: payers you debit and your customer's payout account	Counterparties
Payments	Incoming ACH and wires, ACH debits, check deposits, book payments, and payouts	Payments
Webhooks	Notifications when money arrives, clears, or is returned	Webhooks
Tags	Key-value pairs that link Unit objects to invoices and IDs in your own system	Tags

Step 1 - Set Up Your Program

Sign up for a sandbox and create an API token from the dashboard. Using the API covers authentication, the JSON:API request format, and idempotency keys. We recommend sending an idempotency key with every request that creates something, so you can safely retry it.

Webhooks matter more in AR than in almost any other use case. Much of the money that reaches your customers is started by someone else, such as a tenant's bank transfer or a check scanned at a lockbox, so a webhook is the first you'll hear of it. Subscribe to webhooks before you build anything else.

Step 2 - Onboard Your Customers

Every property manager on Property Hero becomes a Unit customer, with a wallet to collect into and a linked bank account to pay out to. Most companies run these steps when a customer turns on AR in their product.

Create the Customer

Submit a business application (businessApplication) for each property manager. It collects the information needed for KYB (know your business). When the application is approved, Unit creates a business customer. Approvals can be instant or go to manual review, so listen for application webhook events rather than assuming an immediate result.

Open a Wallet

Create a wallet account (walletAccount) under each customer, referencing your Wallet Terms. In the diagram it's the orange box. Drive this step from webhooks. When the customer.created event arrives, create the wallet for that customer, then carry on with the steps below. The customer only exists once the application is approved, so don't try to create a wallet any earlier.

In AR, the wallet is where every receivable lands. It has its own routing and account numbers, which you can put on invoices so payers can send ACH credits straight to it. Its balance builds up as payments arrive and returns to $0 when you pay out. We recommend tagging each wallet with your internal ID, for example "property_manager_id" = "456", so every incoming transaction can be matched to a property manager without an extra lookup.

Wallet Terms decide what each wallet can do, so configure them with Unit for your AR flow before you go live. For AR, the settings that matter most are:

• Clearing periods on check deposits and ACH debits, which control how soon collected funds can be paid out.
• Limits on check deposits and ACH debits, per payment and per day.
• Fees applied at the wallet level.

If dynamic clearing periods are enabled for your program, you can shorten the clearing period on individual ACH debits from payers you trust and keep the default for new or riskier ones. You can also assign different terms to different groups of customers. In sandbox, use walletDefault. In production, Unit configures the terms with you. Learn more about wallets.

This is a decision point: one wallet per property manager is the simplest setup. If a property manager needs each building's funds kept separate, open one wallet per building and tag each with its building ID.

When customer.created arrives for a property manager:

1. Create the wallet, as above.
2. Connect their payout account. The property manager wants the money to end up in their own bank, Chase in our example. Have them link that account through Plaid, then create a counterparty (achCounterparty) from the processor token. You never handle raw account numbers, and you can optionally verify that the account holder's name matches. Payouts only ever credit this account, so credit-only permissions are enough. If you also plan to debit the property manager, for example to recover a returned payment, allow debits as well.

Add Payers You Will Debit (Optional)

If you pull payments from tenants or buildings instead of waiting for them to pay, each payer needs a counterparty with debit permission. Their bank details usually come from a Plaid link or an authorization form in your product. Tag each payer counterparty with your own payer_id. Payers who pay by check or push a bank transfer don't need a counterparty.

Step 3 - Collect a Payment

In AR, money arrives in two ways. Some payments are started by the payer, like a bank transfer or a mailed check. Others you start yourself, like depositing a check or pulling an ACH debit. Either way it lands in the wallet, where you take your fee and pay out the rest. We'll follow Property Manager 1's three $1,010 receivables through to the $3,000 payout.

Receive Payments Others Send

Payers can send an ACH credit, a wire, or a real-time payment (RTP) straight to the wallet's routing and account numbers. You don't call anything to receive these. You find out through webhooks: subscribe to transaction and received ACH events, and match each incoming payment to an open invoice.

Collect Payments You Start

You can bring money in yourself in four ways:

• Check deposit. Customer 1 hands over a paper check, and the property manager photographs it in your app. Submit it as a check deposit (checkDeposit) into the wallet. We recommend the Check Deposits UI component, which handles image capture and validation for you.
• Lockbox. Customer 2 mails a check to a lockbox. The lockbox provider scans each day's checks and sends you a batch. Your service splits the batch and creates one check deposit per check, tagged with its invoice ID. Learn more about lockbox deposits and lockbox providers.
• ACH debit. Customer 3 has authorized you to pull from their Wells Fargo account. Originate an ACH debit (achPayment with direction Debit) from their counterparty into the wallet. Amounts are in cents, so $1,010 is 101000.
• Real-time payment (RTP). Prompt the payer to pay by RTP, for example with a pay-now option on the invoice that shows the wallet's account details. Funds arrive in seconds, 24/7, and RTP payments are final. The payer's bank must support RTP. Learn more about receiving RTP.

Each method trades speed against risk differently:

Method	Who starts it	When funds are usable	Main risk
ACH credit or wire in	The payer	When received	Low; matching it to an invoice
Real-time payment (RTP)	The payer, or you prompt it	Within seconds, 24/7	Low; RTP payments are final and can't be returned. Only payers whose bank supports RTP can use it
Check deposit	You	After clearing, typically about 5 business days	The check is rejected or returned
Lockbox	The payer mails it, you deposit it	After clearing, same as a check deposit	Same as a check deposit, plus batch ingestion errors
ACH debit	You	After your clearing period	The payer's bank returns it (insufficient funds, unauthorized)

Check deposits move through review and clearing before funds are released, and they can be rejected. ACH debits can be returned days after they look settled. Treat money as collected only once it has cleared, and show each receivable's real status in your UI rather than a single "paid" flag.

Collect Your Fee

When the receivables clear, charge your fee with the Fees API. Create a fee (fee) against the property manager's wallet, and the amount moves to your revenue account. In the diagram, Property Hero charges one $30 fee for the month, tagged "invoice_period" = "11-2025". You could charge $10 per receivable instead. Per-receivable fees are easier to trace and to reverse with the same API, and a monthly fee keeps the ledger short.

Pay Out to Your Customer

Send the balance to the property manager's linked bank account with an ACH credit (achPayment with direction Credit). In the example, $3,000 goes to Chase, tagged with the same invoice_period, and the wallet returns to $0. For large or urgent payouts, use a wire instead, if it's enabled for your program.

When to pay out is a decision point for your business:

• As each payment clears. The property manager gets money fastest, but you send many small payouts.
• On a schedule (daily, weekly, or monthly). There are fewer payouts, reconciliation is cleaner, and balances stay in the system longer, which earns float (see the next section).
• After a hold. Adding a speed bump before payout protects you against late returns from risky payers or new customers.

Track Status and Reconcile

• Webhooks. Check deposits report their status as they move from pending through clearing to sent or rejected. ACH payments report sent, returned, and so on. Verify each event's signature before you act on it.
• Returns. A check or debit returned after you've paid out leaves the wallet short. Decide in advance whether you recover it from the next payout or by debiting the property manager.
• Reconciliation. Tags on a payment are copied to the transactions it creates. With property_manager_id on the wallet, invoice_id on each receivable, and invoice_period on fees and payouts, every ledger line maps back to an invoice and a statement period in your system.

Step 4 - Monetize Your Program

An AR program can make money in three ways.

• Transaction fees. Charge per receivable, for example $10 per collected invoice, $0.50 per ACH debit, or $7 for a wire payout, and charge it with the Fees API as shown above. Fee schedules can differ by customer, and you can charge more for faster payouts or for advancing funds before a check clears.
• Float. Receivables sit in the wallet between arrival and payout, and even more so with scheduled payouts or speed bumps. Those balances earn float across all your customers' wallets, which is paid to your revenue account automatically.
• Software fees. Bundle AR into a higher plan, such as a $850 a month Pro subscription, or charge for access to the feature on its own.

Next Steps

• Build the whole flow in sandbox, starting with the API quickstart.
• Use sandbox simulations to test incoming ACH, check deposits, and returns before you go live.
• If your customers also pay vendors, see the accounts payable tutorial. The same wallet can handle both.

This tutorial covers the common shape of an AR program, and yours will have its own edge cases. If you're designing one, talk to our team. We're happy to look at your flow of funds with you.