Put a Brex card in an employee’s hand and the product explains itself. There is a budget, a purchase, a receipt, an approval rule, and eventually an accounting entry. Modern Treasury becomes legible one floor below, where a software team creates a payment order, listens for a webhook, updates a ledger, and investigates a transfer that returned three days after everyone thought it was done. Both products deal with business money. They simply meet it at different moments.
That distinction gets blurred because fintech companies expand. Brex has APIs and payments. Modern Treasury has an operations application and an integrated payment service provider. Each can point to a feature that appears in the other’s territory. Yet a useful buying decision should follow the center of gravity, not the farthest edge of a product map.
Brex’s center is company spend. Its own developer overview groups corporate cards with expense management, reimbursements, travel, and bill pay. The people in the loop are employees spending company money and finance teams setting the rules. Modern Treasury’s center is payment operations. Its documentation begins with REST resources, payment orders, internal accounts, counterparties, ledgers, and a sandbox. The people in the loop are developers, finance operators, and product teams building or running money movement.
Employee and finance surfaceCards · budgets · expenses · travel · reimbursements · bill pay
Product and payment-ops infrastructureAPIs · bank rails · payment states · ledgers · reconciliation · webhooks
Begin with the person who feels the pain
A feature checklist starts too late. Start with the complaint. If employees are paying on personal cards, receipts arrive by archaeology, and finance learns about a purchase after it clears, the pain lives at the spend layer. Brex is designed to put policy close to the transaction: issue a physical or virtual card, assign a budget, collect the receipt, and route the exception.
If the complaint is that payouts require brittle bank files, payment status lives in several portals, incoming transfers will not match cleanly to customers, or engineers maintain a homegrown ledger, the pain sits lower. Modern Treasury offers payment objects that represent instructions to move money across rails such as ACH, wire, RTP, checks, and stablecoins. Webhooks expose the lifecycle; ledger and reconciliation products help a system explain what happened.
One product sits in the wallet. The other sits behind the workflow.YesPress field guide
The split is not finance versus engineering. Finance is present in both rooms. With Brex, it writes policy, reviews spend, manages budgets, and closes the books. With Modern Treasury, it helps define controls, approves high-risk money movement, owns cash visibility, and handles reconciliation exceptions. Engineering is also present in both, but the balance changes. A Brex rollout can be led by finance and IT. A Modern Treasury implementation usually demands product and engineering decisions about data models, idempotency, event handling, permissions, and failure states.
A card swipe is an ending and a beginning
For the employee, a card approval can feel like the end of a tiny story. Lunch was purchased. For a finance system, it is the beginning of several chores: categorize the expense, prove the business purpose, collect documentation, post it to the general ledger, and pay the card balance. Brex compresses that sequence into a coherent spend experience.
Product payments have a more unruly plot. A marketplace may collect money from a buyer, record what belongs to a seller, hold a platform fee, and later send a payout. An ACH instruction may be accepted and still return. A wire may carry reference data that operations needs to preserve. A customer balance may need to update immediately even though cash settlement takes longer. Modern Treasury’s payment and ledger abstractions are designed for this machine room.
This is why “Can it send ACH?” is a weak comparison question. Brex’s Payments API can manage vendors and send ACH, domestic wires, and checks. Modern Treasury can also originate payments. The architectural question is what surrounds the transfer. Is it one capability inside a broader company-spend system, or is payment orchestration itself part of the product and its operating model?
If a finance team mainly wants to pay its own vendors alongside cards, budgets, expenses, and travel, consolidating that work in Brex can reduce context switching. If a company needs to build dynamic counterparties, expose payment status in its own product, keep an operational ledger, or route substantial flows across several rails and accounts, Modern Treasury’s infrastructure orientation becomes more relevant.
The honest overlap lives at the edges
Software categories are drawn with thick markers; products are built with fine pens. Brex publishes APIs for accounting, budgets, expenses, payments, teams, transactions, and travel. A sophisticated customer can automate internal workflows around it. Modern Treasury provides an application where operations teams can inspect and manage payments, so it is not merely invisible code.
Current corporate context matters too. Capital One completed its acquisition of Brex in April 2026, and Brex continues under Pedro Franceschi as CEO. The deal adds bank-scale distribution and underwriting to Brex’s spend platform, but it does not turn every Brex workflow into general-purpose payment infrastructure. Modern Treasury, meanwhile, has widened its rails. In 2026 it launched an integrated payment service provider spanning fiat and stablecoins, along with Global USD Accounts. Its remit is broader than the bank-connectivity software with which many buyers first associated the company.
Brex is a financial technology company, not a bank. Its disclosures identify partner banks and regulated affiliates for specific card, account, treasury, and payment services. Buyers should evaluate the actual product, entity, geography, and rail involved.
Expansion increases the chance of a legitimate either-or decision at a narrow boundary. A company choosing how to originate its own vendor payments may compare both. So might a team assessing a particular reconciliation workflow. Those cases deserve a requirements test, not a category slogan. But they do not erase the larger difference in intended user and system role.
The case for buying both
Imagine a software marketplace. Its employees travel, buy cloud services, and reimburse customer visits. The company also collects funds from buyers and pays thousands of sellers. Brex can govern the first stream: who may spend, on what, under which budget, with which evidence. Modern Treasury can power the second: how product-initiated transfers move, how balances are represented, and how exceptions reach operators.
The two systems still need boundaries. Decide which is authoritative for each kind of payment, vendor, counterparty, balance, and accounting output. Avoid sending the same instruction through two platforms or maintaining two operational ledgers for one flow. Give every integration an owner. Document which system wakes someone up when a payment fails.
The best stack is not automatically the stack with fewer vendors. Consolidation is valuable when it removes duplicate data and work. It becomes expensive when a general tool is stretched into a job that demands a dedicated data model, or when specialist infrastructure is forced to impersonate a polished employee product.
Make the demo carry real weight
A polished happy path proves very little. Give each vendor a messy example drawn from your own month. For Brex, that might be a trip changed after booking, a purchase split across departments, a missing receipt, or a contractor who needs a tightly limited virtual card. Ask the finance operator who would resolve it today to run the scenario. Count the handoffs, not the clicks.
For Modern Treasury, bring a returned payment, an ambiguous incoming transfer, or a payout that must update an internal balance before settlement. Ask an engineer to trace the event from API request through webhook, ledger posting, reconciliation, and repair. Inspect how the system preserves identifiers and audit history. A payments platform earns trust in the exception path.
Then price the operating model, not only the contract. Include implementation, ongoing engineering, finance administration, accounting cleanup, support response, and the cost of a failed or misrouted payment. Brex may replace several spend tools and reduce human follow-up. Modern Treasury may replace internal infrastructure and bank-specific logic. Those savings occur in different budgets, which is another reason a single feature table can mislead.
Before either demo, draw one dollar’s journey. Mark who requests it, who approves it, which account funds it, which rail moves it, when the books recognize it, and who handles the exception. Then draw the system boundaries. If the dollar begins with an employee purchase, Brex will often dominate the conversation. If it begins as an event inside your product, Modern Treasury will often have more to say. If your diagram contains both, your vendor list may too.
Frequently asked questions
Are Brex and Modern Treasury direct competitors?
They overlap at some edges, especially business payments. Brex centers on corporate spend, cards, expenses, travel, and business accounts. Modern Treasury centers on payment orchestration, ledgers, reconciliation, and developer infrastructure.
Can a company use both?
Yes. A company can use Brex for employee and vendor spend while integrating Modern Treasury for product payments, payouts, bank connectivity, and ledger workflows.
Which product is more employee-facing?
Brex. Employees may directly use its corporate cards, mobile app, travel booking, reimbursement, and expense workflows.
Which product is more developer-facing?
Modern Treasury. Its core workflows use APIs, payment objects, webhooks, ledgers, and reconciliation, although it also provides an interface for operations teams.
What should buyers evaluate first?
Map the user, money flow, payment rails, approval model, ledger owner, reconciliation needs, geographic scope, and required integrations. Then compare coverage, controls, implementation effort, and price.