Many solve getting an invoice in. Almost nobody solves what happens after.
This one kept me busy for months, and it is the topic where the gap between the promise and the working day is widest. It is also the topic that is quietly moving on: the specification is written, the questions are answered, and the development team at soluvine has taken over the build. What follows is the thinking that got it there.
There are well over ten products on the market for this. Ask the companies using them and you hear the same sentence every time: it covers a certain part of what we need. Never the whole thing. And now, in the age of AI and MCP, customers are being told the problem is finally solved — but listen carefully and they will only confirm that for very specific areas.
Reading the invoice is not the hard part. Getting an external document into Dynamics 365 happens in seconds. The challenge starts inside D365, where a human being now has to work out whether what arrived is actually correct.
In practice that means: someone calls the buyer. Someone asks the warehouse whether the goods even arrived. Someone checks whether the agreed price was invoiced, whether the discount is right, how long the cash-discount period still runs. I once sat down and counted the things that can need clarifying on a single incoming invoice.
Distinct questions that can come up on one incoming invoice — before anyone is allowed to post it. Which ones appear depends on the industry, the contract and the supplier.
The full list of clarification cases — forty and counting — the figures behind them and the four entry points into Dynamics 365 are in the post about it: Forty clarification cases are not a capture problem
The system already knows what it was expecting. Price, quantity, delivery date, discount, tolerance — all of it is in Dynamics 365 before the invoice ever arrives. So the question is not whether to hire another person, but why anyone should be reading through order lines by hand at all.
Capture systems cannot know how Dynamics 365 posts
Every capture vendor I have worked with runs into the same wall. They read the document beautifully. Then they have to decide where it goes — and that decision needs the posting logic of Dynamics 365: entry points, dimensions, tax codes, tolerances, approval routes, the rules a company has spent years configuring. None of that is visible from outside, and rebuilding it in a capture product is a project nobody wants to own.
So I am building a second piece alongside the invoice solution: a broker that exposes the complete Dynamics 365 posting logic over a REST API. It does not work as one big request. It works as a conversation — the partner sends a value, the broker checks it against live D365 data and answers with what is possible next; the partner picks, and the next question follows. Each round narrows the field, and none of it is guesswork, because every answer comes from the customer's own configuration.
This is the part where I would rather talk than write. If you build capture software, or you are on the other side and tired of the gap between the two worlds, I would genuinely like to hear from you — those conversations are what decides which rules get built first.
How this ends, for me: the wireframes are done, the prototype has been clicked through by enough people to be trusted, and the build now belongs to the developers at soluvine — the ones who know the platform’s rules and its update cycle. I stay with it until the first rollout, because the last twenty percent of any idea only shows itself in a real company, on a real month-end. After that the file leaves my desk for good. And then, knowing me, the desk will not stay empty: the next version of this idea is already forming, and the way I hold on to it is the way I always do — a mockup, then a prototype you can click. There will be something to show.