Lithic unifies card and ACH reconciliation
Bo Jiang, CEO of Lithic, on the power of the cards as a digital payment rail
Lithic is using ACH to turn card issuing from a point tool into a payments control layer. In practice, that means a customer can issue virtual cards, send some vendors ACH when card fees do not work, and still see one ledger of what was authorized, what settled, what fees hit, and what cash landed in the bank account. That unified record matters most for software platforms like Order that need clean buyer, vendor, and accounting workflows across multiple rails.
-
The hard part is not moving money, it is matching every payment to the right invoice, vendor, fee, and bank deposit. Lithic had already rolled out a settlements API aimed at reconciling network reporting and fees to bank cash, and ACH extends that same visibility to payments that cannot run on cards.
-
Order shows the concrete use case. It already uses Lithic virtual cards to pay vendors, issue vendor specific cards, and roll spend into one consolidated bill. It pays some catalog vendors by ACH, expects ACH to expand, and sees the value in pairing payment origination with PO and invoice data so deposits can auto match into QuickBooks, Sage, or NetSuite.
-
This fits Lithic's broader position in embedded finance. Rather than becoming a full banking stack, it has historically competed as a modular issuer processor that developers can plug into a custom setup. Adding ACH as an add on preserves that modular model while making Lithic more like an embedded payments channel than a single rail API.
The next step is a broader embedded payments platform where the rail becomes invisible and the software decides what to use. If Lithic keeps layering ACH, card controls, settlement data, and modular integrations into one workflow, it can move closer to the center of how vertical SaaS and fintech products manage payables, cash visibility, and reconciliation.