Money in and money out are two different products.
Coming in: card and bank payments on any invoice, at a card rate we guarantee to beat. Going out: vendor payments released from an approved run, priced per payment rather than as a share of the amount. Both settle through the same wallet, and every settlement writes its own journal entry.
The rate-beat guarantee, and exactly what it covers.
We will beat the effective card rate you are quoted to take money in. Send a recent processing statement, we price the same month on our rails, show the delta line by line, and put the guarantee in your agreement. If we can’t beat it, don’t switch. This is a commercial promise about inbound card acceptance. What it costs to send money out is a separate, per-payment price, and it is published.
Two directions, priced on what each one costs.
A processor takes a percentage of your success on the way in. A bill-pay provider takes a spread on the way out. Bank rails work like neither, and when payments and the ledger are one system, we don’t need to either.
Acceptance and disbursement are live, and switched on per company rather than on by default. Same-day ACH, RTP, FedNow and push-to-card are picked per payment, so an urgent bill and a routine one do not have to cost the same. Every price is on the pricing page.
One wallet in the middle, and nothing re-keyed on either side.
Customer money lands in your wallet. Approved payment runs draw it down. What is left sweeps to your operating bank. Each of those legs is a posting in the same ledger the invoice and the bill already live in.
Money coming in
Every approved invoice can carry its own pay link, a tokenized, expiring URL to a hosted pay page that emails itself to the customer’s billing contact with the invoice PDF attached. The customer pays by card or by bank. The card details are typed into the processor’s own browser widget, so no card number ever reaches us, and the receipt email sends itself the moment the payment posts rather than when someone remembers.
- Pay link on the invoice, plus a public pay page with the PDF attached
- AutoPay on a saved method, bulk application across invoices, partial payments and unapply
- Subscription charging with its own tokenized pay page for the customer to update a card
- Choose per company whether you absorb the processing fee or surcharge it, set in basis points, overridable per legal entity
- A refund, dispute or chargeback reverses the receipt and puts the invoice back to open
Money going out
Releasing an approved payment run originates the disbursements. The settlement webhook posts the entry through the same validated function a person recording a manual payment would run. If a payment returns, the entry reverses and that run item fails, so the bill goes back on the list instead of quietly disappearing.
- Vendors enter their own bank details in the portal and they are tokenized, so your staff never handle them
- New bank details land pending review, and whoever submitted them is barred from approving them
- Approve and release are different permissions, and release is reserved, so a broad Manage badge does not inherit it
- Per-item settle and fail, a funding view before you release, and cancel while nothing has left
- The approval chain and the three-way match ahead of all this live on AP & bill pay
The wallet
The wallet is a real GL clearing account, mirrored to the penny. You top it up by pulling from your own operating bank, read the available and pending balance live, and let it settle down again when the processor sweeps to your account.
- A wallet per legal entity, so the clearing account matches the entity the money actually moved for
- Move money between two of your own entities’ wallets, and the due-to and due-from legs write themselves
- Every sweep out posts Dr operating bank, Cr wallet clearing, and every top-up posts the reverse
- Every movement in or out of it is a posting, so the wallet and the clearing account don’t drift apart
Every dollar books itself
A settlement here is not a notification, it is a posting. The webhook runs in the current open period, is deduplicated by event id so a redelivered event can never post twice, and is signature verified before any of that.
- A customer receipt posts Dr wallet clearing, Cr accounts receivable, and relieves the invoice
- The processing fee posts as its own entry, Dr fee expense, Cr wallet clearing, so the clearing account is never left overstated
- In surcharge mode the payer funds the fee, the merchant nets the full invoice, and you book no fee expense at all
- A vendor payment posts Dr accounts payable, Cr wallet clearing, and settles its run item
- If the fee account isn’t configured yet the receipt is held rather than posted wrong, and it says so
- There is no download-the-processor-CSV step, because the processor events and the entries are the same system
Card spend and receipts
Corporate cards sit on the price list at no monthly fee, with 1% of card spend credited against your bill. Cards are issued from the same wallet the rest of your money moves through, so the spend is coded and the cash back is credited without a second system. What runs today works on the cards you already carry.
- Connect bank and card accounts through Plaid, including the reauthorization flow when a bank expires consent
- Text a receipt photo from the mobile number on your profile and it files itself into the vault, classifies, and attaches to the matching transaction
- A sender we can’t resolve to exactly one person and one company is stored nowhere rather than guessed onto the wrong books
- Every line is coded through the same ladder the rest of the books use: your decision, then a rule someone wrote, then this company’s own history, then AI, always queued
- A funds check against the live budget version, set to warn or to block, and a notification when a bill approval crosses a department’s line, with burn showing budget, committed and actual
Turned on deliberately
Payments are opt in per company, not on for every tenant, and the plumbing underneath is built to be boring.
- Onboarding per company and per legal entity, through a hosted invite the merchant completes themselves
- Acceptance, disbursement and the Stripe connector are three separate switches
- Moov webhooks are signature verified and event-id deduplicated, Plaid webhooks are JWT verified
- Payment receipt PDFs, a payments-ready queue, and unapply on anything already applied
“How much cash do we have?” Answered from the accounts.
Balances come back from the connected accounts themselves, never from a number she worked out in her head, and anything that needs a decision comes back as a draft. She never moves a dollar herself. Approving a transfer and releasing a run are human actions behind their own capabilities.
A processor, a bill-pay tool, and the person who ties both back to the books.
You pay one company to take money in, another to send money out, and someone’s week to agree both against the ledger at month end. Here the money and the ledger are one module, so the third cost stops existing.
Nothing to reconcile
The events that move the money and the entries in your books are the same system. No export, no match, no month-end guess about which deposit was which.
Priced per payment
ACH is $1.99, or $4.99 same day, in either direction. Card acceptance is quoted against the statement you bring us. Plans start at $59 and none of them charge per user.
One record, both directions
The customer you collect from and the vendor you pay are records the ledger already holds. Nothing is re-keyed into a payments tool and synced back.
Payments are one leg of deal to cash.
Send one statement and one payment run.
We price the same month on our rails, both directions, and show the arithmetic line by line. If we can’t beat what you pay to accept cards, we’ll tell you that too.
Let’s begin