The payment had arrived. That was the good news. The less good news was that nobody could say, without a small expedition through bank feeds and invoices, what it had paid for. Accounts receivable contains many such triumphs: money is present, certainty is absent, and a spreadsheet waits with the patience of a Victorian creditor.
Brodie Marshall knew this landscape before he ever wrote production software. Early in his career, he audited accounts receivable across several companies. He saw collections as finance teams see it, not as a clean sequence in a product diagram but as a pile of exceptions. A customer pays several invoices at once. A lockbox compresses six payments into one deposit. A remittance note vanishes somewhere between a buyer and a bank. The cash is real; the context has gone missing.
Years later, Marshall would join Monk in New York as a founding engineer and help build software for this exact problem. It is tempting to call that a career change. In practice it looks more like a loop closing. He moved from checking the ledger to designing the machinery that keeps it legible.
The education of a useful outsider
Marshall was not trained as a computer scientist. At Northeastern University, where he studied from 2015 to 2019, his academic world was finance and economics. He graduated magna cum laude with an economics minor. Code arrived by a side door: he taught himself programming by making games.
Games are an amusingly apt apprenticeship for financial systems. Both are worlds made of rules, state and consequences. The difference is that a bad game mechanic annoys the player, while a bad payment match can distort a company's view of what it has collected. The habit of constructing rules carried over. The tolerance for playful failure could not.
He spent three years in finance and, by the time Monk recruited him, had accumulated five years in engineering. His public technical vocabulary includes JavaScript, TypeScript, React and Node.js. Outside work, he built a learning copilot used by students at prominent universities. Those details point to the pattern more than any title does: Marshall seems to learn by building a working thing, then making the thing answer harder questions.
His arrival at Monk in November 2025 produced the sort of statistic startups enjoy: 15 pull requests in nine days. The number is lively, but the assignment is more revealing. He went to work on payment matching, the point where incoming cash must be connected to open invoices. It was a software problem he had already encountered as a finance problem.
Certainty first, cleverness second
Artificial intelligence in finance has an image problem. The demo is often smoother than the month-end close. Models are good at reading untidy information and finding patterns, yet their answers are probabilistic. Accounting, meanwhile, remains stubbornly devoted to amounts that add up. The useful question is not whether one philosophy defeats the other. It is where each belongs.
The cash-application system Marshall has described at Monk answers with three tiers. First come deterministic matches. When the system has complete confidence, it connects payment and invoice automatically, with no language model involved. Then come custom rules, written around patterns specific to a customer. Only after those two layers does an agent tackle the residue, making predictions from transaction and invoice history.
Exact evidence and complete confidence. The match happens automatically.
Known patterns become customer-specific logic, without an LLM.
Ambiguous cases get a prediction, visible reasoning and human review where needed.
The architecture is modest in a useful way. It does not ask a model to perform certainty. It reserves probabilistic reasoning for cases where fixed rules are insufficient. When a person accepts or rejects a suggested match, that decision becomes a labeled example. The product learns, and the evaluation set grows from actual work rather than an engineer's imagination of it.
Marshall has argued that evaluations should begin early, even when the dataset is imperfect, and should belong to the company rather than to engineering alone. Non-technical teammates can run experiments and contribute examples. A failed case is not merely a defect to close. It is new material for testing the next version.
The bank knows less than you think
One reason cash application remains stubborn is that a bank feed can be accurate and still be unhelpful. Consider a lockbox deposit. Six customers send six payments with useful remittance details; the bank feed presents one aggregated transaction. Somewhere in that compression, the clues needed to close six invoices disappear. The aging report now tells a technically defensible lie: cash appears late even though it has arrived.
Monk's 2026 cash-application update lets customers upload lockbox files and check images. The software extracts the missing detail, enriches the bank transaction and attempts the match again. Marshall put the principle neatly: every match should be certain or explainable. The second half matters. In finance, an answer without lineage is simply a fresh mystery wearing a nicer interface.
By June 2026, Monk reported a match rate of roughly 80 percent for this system, trending upward as customer-specific information accumulated. The percentage is less interesting than the restraint around it. Bulk approval applies only when amounts match exactly. Differences require individual inspection. The system is designed not merely to finish work but to preserve the point at which confidence gives way to judgment.
A contract enters; an invoice leaves
Payment matching sits near the end of the contract-to-cash journey. Marshall has also presented work near its beginning. In a product walkthrough, he showed contracts arriving through integrations or a direct upload, then moving through models and an internal reasoning layer that extract billing terms. The aim is near-real-time processing, rather than leaving a signed agreement in a queue until the next business day.
Here again, the division of labor is the product. Models read performance obligations and complex billing structures. Deterministic code handles what should never be guessed. A person confirms low-confidence or consequential details. The resulting customer record links contracts, schedules, invoices and documents, giving later collections work the context it needs.
This is not glamorous material. Purchase-order fields, prorations and payment deltas rarely appear in cinematic visions of artificial intelligence. They are, however, where a business discovers whether its automation is useful. Marshall's finance background gives him a particularly good view of the anticlimax. The machine's grand achievement is that the invoice goes out correctly and the payment ceases to be mysterious.
The ledger as a biography
In April 2026, Monk announced a $25 million Series A. The company said it was managing more than $2 billion in receivables and reported customer improvements in collection time and response rates. Marshall shared the announcement, but his public work remains fixed on the mechanics: evaluation loops, contract extraction, remittance detail, matching rules. Funding enlarges the canvas. It does not reconcile a single deposit.
His story is still short in public, which suits the subject. There is no elaborate founder mythology and no conversion scene in which software suddenly vanquishes accounting. There is a finance graduate who became an engineer, carrying the old discipline into the new one. He has seen accounts receivable from the audit side and the application side. The connection is almost suspiciously tidy.
The smaller episodes reinforce it. At a Monk hackathon, Marshall built an internal knowledge base over the company's repository, using retrieval and a fleet of sub-agents to index descriptions of the code. It was a different problem from reconciling payments, but the instinct was familiar: take a large, messy body of information, preserve where the answers came from, and make the useful parts easier to retrieve. The ledger had changed shape again.
The aspiration visible in his work is not to make finance disappear. It is to remove the repetitive investigation while keeping the proof. Certain cases should pass cleanly. Ambiguous ones should announce themselves. Humans should spend their time on the exceptions worthy of human attention.
A ledger is a record of promises kept, delayed or disputed. Marshall's work asks software to read those promises without becoming another source of ambiguity. The machine may be clever. The books must still close.