Moss, Vertice and Cledara: how one software stack ends up in three systems
A finance lead at a Berlin software company walked us through how a new tool gets bought. Someone emails their team lead. The team lead emails the C-level. The C-level emails finance. Finance creates a card in Moss with a hard limit. The contract goes into Vertice so someone can watch the renewal. Three systems and an email chain, for one subscription.
None of those tools is doing anything wrong. Moss is very good at cards and pre-accounting. Vertice is very good at negotiating. Email is where approvals go when nothing else owns them. The problem is the seams between them, and the seams are where the money and the time leak out. This post is about what it looks like to run software payments, contracts and approvals in one place, and when it's worth doing.
Key takeaways
- Moss, Vertice and email each cover one slice of a software subscription: the payment, the contract and the decision. Nobody owns the subscription itself.
- The seams cost real money: duplicate tools nobody noticed, usage-based AI bills that hit a card limit, and renewals that pass without anyone deciding.
- One list of every tool, with its owner, card, renewal date and contract, turns approvals from an email chain into a two-step flow.
- For DATEV, Cledara matches every payment to its invoice and coding, then exports it for your Steuerberater or pushes it through the API on every plan.
- You can keep Moss for everything that isn't software. The point is to give subscriptions a home, not to rip anything out.
- On the Cledara platform, 27% of software spend now goes to AI-native tools, which is the spend a card limit handles worst.
How a finance team ends up running Moss, Vertice and an email chain
It happens in order, and each step is sensible. First, cards. Moss arrives so people stop paying for things on their own cards and so finance stops typing receipts into DATEV. It works, and software goes onto Moss cards along with everything else. One card per tool, a hard limit on each, finance creates the card after approval.
Then contracts. Someone misses a renewal, or gets tied into an extra year because the notice period passed, and the company buys Vertice. Now there's a place for contracts, a renewal date, and a team who'll negotiate with vendors on your behalf. Also sensible.
Approvals never got a tool. The request still starts with an email, and in most companies we talk to it still needs the C-level to sign off even when the department head already has. One finance lead told us the C-level approval was mandatory for every tool, however small. So the team that's supposed to be closing the books is forwarding emails about a design plug-in.
What Moss and Vertice each do well
Fair's fair, and both tools deserve the credit.
Moss brings corporate cards, supplier invoices, reimbursements and procurement into one platform for European businesses, and more than 7,500 of them use it. Its real strength is pre-accounting: it captures and codes documents as they arrive, matches transactions and prepares the close, and Moss Accounting is built for DATEV. If you run a German finance team, that matters. For subscriptions, Moss can issue a card per recurring payment with a limit, show what you pay each merchant monthly and flag duplicates. (Our full Moss vs Cledara comparison goes deeper.)
Vertice is a procurement platform. Its buyers negotiate renewals using benchmarks across 32,000+ vendors, its AI agent drafts the strategy and the vendor emails, and on its SaaS Purchasing plan the savings are contractually guaranteed. It also covers sourcing, vendor onboarding and risk. Its starting prices (from $30,000 a year for Intake-to-Procure, as of its published pricing in late 2026) tell you who it's for: companies with large software and cloud budgets and a procurement function to run it. (See our Vertice vs Cledara comparison.)
Email is good at one thing. Everyone has it.
Where the seams between Moss, Vertice and email show
Each tool sees its own slice of a subscription. None of them sees the subscription. That's where the problems come from, and the finance teams we talk to describe the same five.
The AI one is getting bigger every quarter. On the Cledara platform, 27% of software spend now goes to AI-native tools, up from about 3% two years ago. Those tools bill on usage, sometimes several times a month, and a card limit does one of two things when the bill climbs: it pays, or it declines and the product team loses access. One finance lead told us they were "bombarded" every time a team hit a credit limit. The limit was doing its job. The job was wrong.
Running software payments, contracts and approvals in one place
Here's what the same subscription looks like when one system owns it. We'll use Cledara, because it's what we build, but the shape is the point.
- Someone requests a tool. In Slack or in Cledara, with the cost, the team and what it's for. The request is checked against the tools already on the list.
- Rules route the approval. Under a threshold you set, the manager approves. Above it, finance or the C-level. A compliance questionnaire can sit in the flow for tools that handle customer data.
- Approval issues the card. The subscription gets its own virtual card with its own limit and a named owner. Nobody in finance creates anything by hand.
- The contract and renewal date live on the same record. Alerts go out before each renewal, with what similar companies pay for the same tool, and the Negotiation and Renewal Copilot drafts the email to the vendor.
- Invoices arrive by themselves. Email capture picks up the ones that get emailed. Cledara Agent signs in and collects the ones that only ever appear on the vendor's billing page, and matches them to the payment overnight.
- Every payment is coded once, for good. Map each tool to its account, department and cost centre, and every payment for it lands the same way.
Notice what disappeared: the email chain, the hand-made card and the gap between the contract and the payment. The C-level still approves the big things. They just stop approving the small ones.
The DATEV path: what happens to the bookkeeping
This is the question every German finance team asks first, so let's answer it plainly. Cledara syncs natively to Xero, QuickBooks Online, NetSuite and Tripletex. DATEV is not a native integration today.
What Cledara does for a DATEV shop is everything up to the import. Each software payment is matched to its invoice automatically, coded with the account, cost centre and tax treatment you set once per tool, and available as a transaction and invoice export for any period, or as a statement. Your Steuerberater or your in-house team imports that into DATEV the same way they import from any other source. The API is included on every plan at no extra cost, so a direct push is a small build if you want one.
In practice, most DACH finance teams we work with keep Moss for supplier invoices, reimbursements and the DATEV-ready pre-accounting it's built for, and move software to Cledara. Both end up in DATEV. What changes is that the software line arrives with the invoice attached and the owner named, instead of as a card charge someone has to chase a document for.
Keeping your vendor relationships
One thing we hear from finance teams that have looked at negotiation services is that they'd rather keep the vendor relationship themselves. They want the data, and they'll make the call. That's a reasonable position, and it's the one Cledara is built around. You see what similar companies pay before the renewal, the Copilot drafts the negotiation, and you send it. The vendor still knows you.
It's also fine to want the opposite. If software is a seven-figure line and you'd rather hand the negotiation to specialists with guaranteed savings, Vertice is a good answer, and some companies run both: Cledara to own every subscription, Vertice to negotiate the handful of large ones. Different jobs again.
A 30-day plan for moving to one place
- Week one: build the list. Export recurring merchants from Moss, pull the contracts out of Vertice, and add the AI tools paid on API keys or personal cards. Cledara data shows a median of 26 software subscriptions per company (May to October 2026), so expect the list to be longer than you think.
- Week two: assign owners and renewal dates. Import the list in bulk, name an owner per tool, and set the renewal date and notice period for anything annual.
- Week three: move the payments. One virtual card per subscription, starting with the tools that renew soonest. The old card stays live until the new one is in the vendor's billing page, so nothing stops.
- Week four: switch on the flow. Set the approval thresholds, connect the Slack channel, connect the owners' inboxes for invoice capture, and turn on Cledara Agent's Invoice Collection for the tools that never email anything.
Set-up is measured in days, and every plan includes help with it. The first month is the only one with any manual work in it.
Keep three tools, or move to one?
- Keep the three-tool setup if software is a small share of what you spend, your procurement team already lives in Vertice, and the email chain is short because there are only a handful of tools a year.
- Move subscriptions to one place if software and AI are among your biggest costs, finance is creating cards and forwarding approvals by hand, and nobody can say today which tools renew next quarter and what they should cost.
- Do both if you want Moss for supplier invoices and pre-accounting, Cledara for every subscription, and Vertice for the two or three contracts large enough to negotiate professionally.
The practical takeaway
Pick your next three software renewals. For each one, can you say who owns it, which card pays it, what the notice period is and what similar companies pay? If the answer lives across Moss, Vertice and someone's inbox, that's the seam. Close it for those three and the rest follows.
Cledara customers save 23% on software on average and get 30+ hours a month back, and most of that comes from the seams rather than from any single tool. Plans are on our pricing page, and Cledara Agent can be added to any of them.
Cheers,
Brad

