Salesforce as an ERP: What Your Finance Team Actually Needs to Make It Work

The Salesforce ERP Trap

You started with Salesforce as a CRM. Then someone added a custom object for inventory. Then a partner built an invoicing module. Then you connected bank feeds. Then the tax advisor started asking questions you couldn't answer from a single system.

Now you are running a company on what is, in effect, a custom ERP — except it was never designed as one. And your finance team is trying to operate inside a system that was built for sales, not for accounting.

This is not a criticism of Salesforce. It is, in the right hands, a genuinely capable operational backbone for a scaleup. But 'in the right hands' is doing a lot of work in that sentence. The hands in question belong to your finance team — and most finance teams are not told what they actually need to make a Salesforce-based finance setup work.

This article fixes that. It covers what a finance team needs to own, monitor, and regularly audit when Salesforce is the operational core — and where the setup typically breaks.

What Salesforce Does Well (and What It Doesn't)

Before listing what your finance team needs, it is worth being honest about what Salesforce is good at in a finance context and where it genuinely struggles.

Where Salesforce earns its place

• Order-to-cash visibility. If your sales team raises orders in Salesforce, your AR team can see the full pipeline-to-invoice-to-payment chain in one place.

• Inventory and fulfilment tracking. With custom objects or a purpose-built ISV solution, you can track goods, deliveries, and third-party logistics providers without a separate WMS.

• Automated invoice generation. A well-built invoicing module in Salesforce can handle domestic and cross-border invoicing, VAT rules, and PDF generation with zero manual input.

• Reporting and dashboards. Salesforce Reports and Einstein Analytics can give your finance and management teams live P&L visibility, AR ageing, and cash flow snapshots — if the underlying data is clean.

Where Salesforce typically creates problems for finance

• Bank reconciliation. Salesforce is not a bank. Most implementations add bank feeds as a data source but lack native reconciliation logic. This is usually a spreadsheet job, which means it is a delay risk.

• DATEV integration. If you are operating in Germany and your tax advisor uses DATEV, pushing clean data from Salesforce requires either an API connector or a manual export step. Both can fail silently.

• Audit trail for finance entries. Salesforce logs activity at the object level, but it does not produce an immutable financial audit trail the way a proper accounting system does. This matters during audits.

• Accruals and journal entries. You cannot post accruals directly in Salesforce. Month-end adjustments happen outside the system, which means your Salesforce numbers and your DATEV numbers diverge.

• Multi-currency and intercompany. If you sell cross-border in different currencies or have multiple entities, Salesforce requires careful configuration and a disciplined reconciliation process to avoid errors.

The Five Things Your Finance Team Must Own

Here is what a finance team running on Salesforce needs to have properly configured, monitored, and maintained. These are not nice-to-haves. Each one is a point where Salesforce ERP implementations break.

1. A clean chart of accounts mapped to Salesforce objects

Every Salesforce object that carries financial data — Products, Opportunities, Orders, Invoices, Expenses — needs to map to a defined GL account. This mapping should be documented, version-controlled, and owned by someone in finance, not by the CRM administrator.

When this mapping is unclear or maintained only in someone's head, you get invoice coding errors, VAT misclassification, and month-end reconciliation that takes two weeks instead of two days. ———————————————————————-- What to check: Open your last three month-end reconciliations. How many lines required manual correction because of incorrect GL assignment? More than five per month is a mapping problem. ———————————————————————--

2. A documented DATEV push or export workflow

If you are using a tax advisor who works in DATEV, you need a defined, tested, and regularly validated process for getting data from Salesforce into DATEV. This is usually one of three setups:

1. API push via a connector like Debitoor, Candis, or a custom integration.

2. Scheduled file export from Salesforce, formatted for DATEV import.

3. Manual extraction by your finance team, reformatted in Excel and emailed to the tax advisor.

Option 3 is how most scaleups start and where most problems begin. The finance team member who knows how to do it leaves. The export format changes. The tax advisor starts receiving incomplete files.

Your finance team needs to own this workflow, document every step, and test it at least quarterly.

3. Bank reconciliation outside Salesforce

Even if your bank feeds connect to Salesforce, the actual reconciliation — matching payments to invoices, clearing open items, flagging unmatched transactions — almost certainly does not happen inside Salesforce. It happens in a spreadsheet. Or it does not happen at all until month-end, when the discrepancies stack up.

The fix is not necessarily to build native reconciliation into Salesforce. It is to define where reconciliation happens, how often, and who owns it. A daily 15-minute reconciliation by a dedicated accounts team member is worth more than a sophisticated automation that no one monitors.

4. Payhawk, Pleo, or expense tool integration

If you are using an expense management tool alongside Salesforce, your finance team needs to know exactly how those transactions flow into the system. Do expense claims automatically code to GL accounts? Does the credit card feed reconcile automatically or manually? Are VAT receipts attached at point of claim or chased after the fact?

This is where errors compound. An expense claim incorrectly coded in Payhawk creates a DATEV error, which creates a tax advisor query, which creates a month-end delay. Finance teams that clean this up proactively rather than reactively close faster.

5. Month-end close checklist tied to Salesforce data points

A month-end close checklist is not a Salesforce feature. It is a finance team discipline. But in a Salesforce-ERP setup, your checklist needs to explicitly reference Salesforce data points — not just accounting entries.

A good checklist for a Salesforce-based close includes: confirming all orders in a delivered status have corresponding invoices, confirming all invoices in an open status have been followed up in AR, confirming the bank feed is current and reconciled to yesterday, and confirming the DATEV export has been sent and acknowledged. ———————————————————————-- The most common reason month-end close drags in a Salesforce setup is not missing data. It is data that exists in Salesforce but has not been confirmed, coded, or pushed to the accounting system. A checklist tied to specific Salesforce report states fixes this. ———————————————————————--

The Warning Signs

These are the signals that your Salesforce-ERP finance setup is starting to break down:

• Your tax advisor is sending queries about transactions that are in Salesforce but not in DATEV.

• Month-end close requires a senior team member to manually reconcile Salesforce totals to bank statements.

• Invoices are being raised and sent from Salesforce but cash application is happening in a separate spreadsheet.

• Your finance team is maintaining a shadow accounting record alongside Salesforce because they do not trust the Salesforce data.

• New team members take more than two weeks to understand the Salesforce finance setup because nothing is documented.

If more than two of these apply, the problem is not Salesforce. The problem is that the system has grown beyond the finance team's capacity to maintain it cleanly. This is the inflection point where many scaleups either invest in process, invest in people, or let the situation worsen until the audit finds it.

What an Embedded Finance Team Adds

When Serana deploys an embedded finance team into a Salesforce-based client, the first two weeks are always spent on the same things: understanding the mapping between Salesforce objects and GL accounts, documenting the DATEV workflow, and rebuilding the close checklist from scratch.

This is not because the client has done anything wrong. It is because this documentation almost never exists. The institutional knowledge lives with one or two people, and the moment those people leave, the knowledge leaves with them.

An embedded team brings a stable, documented operating model into a system that was previously running on tribal knowledge. The Salesforce setup rarely needs to change. The operating discipline around it does. ———————————————————————-- Serana works inside Salesforce setups across DACH and Benelux. If your finance operations are running on a Salesforce-based stack, we can assess the setup and tell you where the gaps are in one discovery call. No commitment required. ———————————————————————-- ———————————————————————-- Book a discovery call — seranapartners.com | info@seranapartners.com ———————————————————————--

Serana Partners B.V. | Keizersgracht 391A, Amsterdam | www.seranapartners.com