d.velop and Salesforce, one invoice process
Invoice matching is the comparison of what was ordered, what arrived, and what has been billed. Done by hand it is slow, and it is the kind of slow that only shows up as a late payment or a duplicate.
d.velop reads the invoice and performs the comparison. Salesforce shows the result on the record where your teams already work. C24 builds the connection between the two, and the leg into your ERP or finance system where the process needs it.
Not every invoice needs all three. Part of the design work is agreeing which comparisons apply to which kind of spend.
What syncs between d.velop and Salesforce
The connection carries documents in one direction and context in the other.
- Invoices, captured and read. Paper, PDF, XML and EDI are captured and interpreted, so the line data exists as data before anyone opens the file.
- Purchase order references. Read from whichever system raised them, so the invoice has something to be compared against.
- Goods receipts and delivery notes. The third leg of the match, and the one most often missing.
- Match status and exceptions. Matched, part matched or in query, written back so Salesforce shows the position without anyone asking finance.
- The document itself, linked not copied. The invoice stays in d.velop and Salesforce holds the reference.
That last one is worth a line of its own. Salesforce charges for file storage and a document management system does not. Keeping the documents in d.velop is both the architecturally correct answer and the cheaper one.
Which way the data flows between d.velop and Salesforce
Salesforce supplies the commercial context. d.velop supplies the document and the verdict.
⇆ Two way→ Out of Salesforce← Into Salesforce
Where the purchase order lives in your ERP rather than in Salesforce, the first row moves and the rest holds. That is the single decision the design turns on.
What a d.velop integration gives you
The point is not that invoices get processed. It is that the people who need to know stop having to ask.
- Invoice status on the account record. Approvals, payments and exceptions visible in Salesforce, so account managers stop emailing finance for a position.
- Fewer touches per invoice. A match that agrees is posted without a person. Only the exceptions reach a human, which is the whole return.
- Exceptions routed rather than chased. A mismatch becomes a task or a queue item with a named owner and a due date.
- An audit trail that survives scrutiny. Every document, every comparison and every approval recorded against the record it belongs to.
- Lower Salesforce storage cost. Files live in the DMS where storage is cheap, and Salesforce holds the link.
How we connect d.velop to Salesforce
Powered by d.velop. Delivered by C24. d.velop is a European document management and process automation company and has been a certified Salesforce ISV partner since 2017. The integration is listed on the AppExchange, d.velop maintains its own Salesforce development team, and the company holds Salesforce certification as an AI specialist for generative AI.
What d.velop does not do is know your business. That is the part we bring: the process design, the Salesforce build, and the decisions about ownership and routing that determine whether any of it works on a Tuesday morning.
The question to settle before you build the d.velop integration
Which system owns the purchase order.
Everything else follows from that. If the order is raised in Salesforce, Salesforce is the source of the commitment and d.velop matches against it. If it is raised in the ERP, the ERP holds the commitment and Salesforce becomes a viewer of the outcome rather than a participant in the decision. Both are workable. They are different builds.
The version that causes trouble is the one where orders are raised in both, informally, because somebody found it quicker. The matching engine will faithfully compare an invoice against whichever order it can find, and the mismatch that results looks like an integration fault when it is an ownership question that was never settled.
The second decision is tolerance. An invoice that is eleven pence out is not a query, it is rounding. Agreeing where the line sits, per supplier or per category, is what determines whether the exception queue is a useful list or one that gets ignored by the second week.
Syte Link: 100,000 invoices a year, matched automatically
Syte Link coordinates waste management and site services for construction projects across the UK. As they grew, supplier invoices reached roughly 100,000 a year, and three full time people were checking every one of them against Salesforce by hand.
Previously, every additional 2,000 invoices required additional headcount. Now, with over 90% of invoices automatically processed and matched, our capacity has increased by up to 10x without increasing resource.
Daryl Rubin, Founder and Director, Syte Link
Built with d.velop Smart Invoice, Salesforce and Sage. Salesforce sales orders sync into d.velop as master data, matching runs against them, and the result is written back to Salesforce and passed to Sage for payment. The design handles several invoices against one order, one invoice against several orders, and pricing discrepancies.
Connect d.velop to Salesforce
Tell us where your orders are raised and how many invoices a month you handle. That is usually enough for us to say what the build looks like.
We can scope the invoice matching on its own, or as part of a wider integration programme.
d.velop invoice matching for Salesforce: frequently asked questions
No. Matching can be built with native Salesforce automation where the volumes are low and the invoices arrive as structured data. d.velop earns its place when invoices arrive as documents, because reading a PDF reliably is a different problem to comparing two numbers.
In d.velop, with Salesforce holding the reference. That is deliberate. Salesforce charges for file storage and a document management system is built for exactly this, so keeping documents out of Salesforce is both the architecturally correct answer and the cheaper one.
Yes, and this is the case most often left manual. Recurring invoices with no order behind them are matched against the agreed terms instead. Common in services, licensing and retainer billing.
It becomes an exception with a reason attached: price, quantity, missing goods receipt or no order found. Where that exception is routed, and to whom, is agreed during design rather than left to whoever notices it first.
No. The finance system still posts the invoice and still holds the ledger. Matching sits in front of that, deciding what is safe to post automatically and what needs a person.
It depends on how many of the decisions are already made. Where the purchase order ownership and the tolerance rules are settled, this is a short piece of work. Where they are not, agreeing them is the project and the build is the easy part.