A finance system can pass every test at go-live and still be wrong — because the ledger structure, the trust or fund separation, or the reporting dimensions were configured without a financial architecture behind them. Twopir Consulting assesses the ledger, the configuration, the customisation and the data before proposing anything, then corrects in place wherever the structure can be repaired. Assessment first. A rebuild is the last option, not the first.
All four figures are from a single documented Accounting Seed build with a 150-employee US client — they are outcomes of a completed implementation, not recovery statistics from a rescue. Read the full case study.
Twopir Consulting has delivered Salesforce and finance systems for 500+ organizations across 12+ years — including deployments we did not originally build, assessed and corrected rather than replaced.
Systems We Build On
A failed finance implementation rarely announces itself. It shows up as a close that keeps getting longer, a report nobody quotes any more, and a workaround that became the process. Every symptom below is one we have been called in on, and each one has a structural cause rather than a software one.
Every period ends with more manual adjustment than the last. Nobody planned it that way; each workaround was reasonable on its own, and together they now consume a week.
The dashboards exist and nobody quotes them. The real numbers live in a spreadsheet somebody maintains, which is the clearest possible signal that the ledger's dimensions were wrong from the start.
Account codes encode entity, department and product because there was nowhere else to put them. Every new reporting question needs new codes, and the chart is now several thousand rows long.
A payment or billing feed stops posting with no alert and no failure record. The gap is discovered weeks later during a reconciliation, and the recovery is manual every time.
The developer has moved on, the requirement was never written down, and the logic is now a constraint on the business. Upgrades get deferred because nobody knows what will break.
Invoices are drafted in a spreadsheet and typed in, approvals happen over email, and the system records the outcome rather than running the process. Adoption did not fail — the design did.
Accounting Seed is an accounting platform built natively on the Salesforce platform, providing general ledger, accounts receivable, accounts payable, billing and invoicing, project accounting and financial reporting on the same platform as the customer records. It is capable software, and in almost every rescue engagement we run it is not the thing that is broken. Accounting Seed's own product documentation covers the product surface; this page covers what to do when a deployment of it is not delivering.
What is usually wrong is architecture: a chart of accounts that carries dimensions it was never designed for, ledger separation that does not hold, automation built in the wrong order, or custom code written against internals that block upgrades. Those are repairable. The assessment is a standalone engagement with its own deliverable — findings, root causes, and options with effort against each — and you are free to take it to another partner or to your own team. We quote remediation only after you have seen it.
Four layers, examined in order, because a symptom in one is usually caused by the layer beneath it.
The service. A written diagnosis first, then remediation only against the findings you accept.
The operating change — mostly things that stop being anyone's job.
A partner who quotes a rebuild before seeing your org is quoting their own convenience. These are the four engagements this work actually breaks into, and the boundary between repairing configuration and writing code is stated rather than discovered.
| Engagement | What it covers | Where the boundary sits |
|---|---|---|
| Assess | A structured review of the ledger, the configuration, the customisation, the integrations and the data, producing written findings, root causes and options with effort against each."Accounting Seed implementation not working" | A standalone engagement with its own deliverable. It ends with the findings document, which is yours — you can act on it with us, with another partner, or with your own team. No remediation is quoted before you have read it. |
| Correct | In-place repair: chart of accounts and dimension restructuring, ledger separation, period and approval configuration, billing rules, reports and dashboards rebuilt so the numbers are trusted again."Accounting Seed configuration fix" | Declarative wherever possible, which is also where it is cheapest and safest. Data corrections are made with an auditable trail and reconciled against a known-good position before and after. |
| Extend | Custom development where the gap is genuinely a missing capability rather than a misconfiguration: allocation logic, bespoke documents, automation the process actually needs."custom Accounting Seed development" | Starts the moment a requirement needs Apex, a Lightning Web Component or an API. Written against supported objects, bulk-safe, tested — never by modifying the managed package. |
| Support | Ongoing close support, period-end assistance, release regression testing, small enhancements and an escalation path — for teams who want the system maintained rather than another project."Accounting Seed managed support" | A retained arrangement rather than a project. It ends where your own team is capable and willing — the goal is to make it unnecessary, and we will say when it has become so. |
If the deployment is sound but the requirement genuinely exceeds configuration, the build-on engagement is custom Accounting Seed development. If the answer turns out to be a different ledger entirely, see ledger migration.
These are the eight areas the assessment covers. Against each is the root cause we most often find behind it — because in this work the symptom and the cause are almost never in the same place.
Usually the root cause. Account codes carrying entity, department or product because the reporting dimensions were never modelled — which is why every new question needs new codes.
Trust, fund or entity separation implemented with a field rather than a ledger, so the separation holds in reports but not in the underlying balances — and not under audit.
Periods left open, approvals routed around, and corrections posted to closed periods. The close takes a week because nothing prevents the previous one from moving.
Flow, triggers and scheduled jobs touching the same records with no agreed order of operations. The symptom is a number that is right most of the time, which is harder to find than one always wrong.
Logic written against unsupported internals, not bulk-safe at real volume, or covered by tests that assert nothing. This is why upgrades have been deferred.
Feeds with no idempotency, no retry and no alerting, so a failure becomes a silent gap. We check what happens when the other system is down, not only when it is up.
Duplicated customers, orphaned records, migrated balances that never fully reconciled. Some reporting problems are structural; a surprising share are simply the data underneath.
Where the spreadsheets are and what they do. Every workaround is a requirement the system did not meet, and mapping them is the fastest route to what the design got wrong.
What moves when it works, and what happens when it does not. On an inherited deployment the second question is nearly always the one nobody answered — which is why so many rescue findings are integration findings.
| Systems | What we check | What we usually find |
|---|---|---|
| Salesforce · Accounting Seed | Whether anyone built an integration between two things that are already the same platform, and what it is now doing to the data. | No integration needed Native — same platform, same database. We do occasionally find sync jobs, duplicate customer masters or field-copy automation built between them. Removing that is often the single largest quick win in an assessment. |
| Payment gateways & processors | Idempotency, retry behaviour, and whether a failed post raises anything a person receives. | Payments → ledger Missing failure records and no alerting, so unapplied payments accumulate quietly until a reconciliation finds them. Consumed by finance, who are usually already aware something is wrong here. |
| Billing & subscription platforms | Whether the ledger and the billing system agree on what was invoiced, and how amendments are handled on both sides. | Billing → ledger Amendments applied in one system and not the other, producing a persistent small difference that gets journalled away each month. Consumed by finance. |
| Bank feeds | Whether reconciliation is genuinely continuous or has quietly become a periodic catch-up exercise. | Bank → ledger Long-unmatched items and manual matching rules nobody documented. The reconciliation completes, but only because someone forces it. Consumed by the controller. |
| Payroll, expense & time systems | Whether cost lands on the right dimensions, which is where allocation problems usually originate. | Source → ledger Postings landing on a default dimension because the mapping was never completed, making departmental and program reporting wrong in a way that looks plausible. Consumed by finance. |
| Corporate ERP · group ledger | Whether period locking holds, and whether late corrections can silently reopen a closed period. | Bi-directional No period lock on the interface, so a correction upstream changes a period the group has already reported. Consumed by group finance, and usually the finding with the highest consequence. |
Where remediation extends past Accounting Seed itself, it runs through our Salesforce integration. Code-level remediation is covered in custom Accounting Seed development.
The fastest way to make a struggling finance system worse is to start fixing symptoms. The assessment runs to completion first, and you see the findings before any remediation is quoted.
We work through the four layers in order: ledger and dimensions, configuration, custom code and integrations, then the data. In parallel we map where the team's spreadsheets are, because each one is a requirement the system did not meet. Typically 1–2 weeks.
A written document: what is wrong, what is causing it, and the options for each with effort and risk against them — including the option of doing nothing where the cost of a fix exceeds its value. This is the deliverable, and it is yours.
You decide what to act on, in what order, and with whom. Some clients take the findings to their own team. Some fix two things and stop. That is a legitimate outcome, and the assessment is priced as a standalone engagement so it stays one.
Structure, configuration, code and data corrected against the accepted findings, in a sandbox first, with a reconciliation against a known-good position before and after each change. Sequenced so the close is never left worse than it started. Typically 3–8 weeks depending on scope.
A full period close run on the corrected system and signed off by finance. Then written handover — what changed, why, and what to watch — so the org is maintainable by your own team rather than dependent on ours.
Durations are typical ranges and are confirmed after Phase 01. A rebuild is quoted only where the assessment shows repair costs more than replacement, and the reasoning is shown rather than asserted.
Both are published Twopir Consulting engagements delivered on Accounting Seed and Salesforce. They are shown here as the standard a corrected deployment is measured against, not as rescue statistics — we do not publish recovery percentages, because a rescue's baseline is the client's own broken system and no honest average exists across them.
Twopir's specialized Salesforce customization enabled efficient integration of third-party systems and streamlined administration and billing, leading to seamless financial operations and enhanced productivity. Automated mass billing and matter management minimized errors across our entire legal workflow.
Manual billing eliminated and financial operations automated on Accounting Seed and Salesforce — 17 automation modules delivered.
Twopir provided Salesforce customisation and integration services to help us build a robust, compliant, and scalable legal operations platform — connecting case management, document processing, and financial systems into one unified workflow. The result was transformative for how we run case-to-cash operations.
Case management, documents and finance connected into one workflow across Salesforce, AWS and QuickBooks.
The commercially attractive answer to an inherited deployment is always a rebuild. It is also usually the wrong one, and the reason most rescue engagements start with a second opinion rather than a first.
Findings, root causes and options are priced and delivered as their own engagement. You can act on them with us, with another partner, or with your own team — that is not a concession, it is how it is scoped.
Most of what is wrong with an inherited deployment is architecture rather than software, and most architecture can be repaired without a blank org. A rebuild is quoted only when the arithmetic supports it.
Every workaround is a requirement the system did not meet. Finding them is the fastest route to what the original design got wrong, and it is the part a purely technical audit misses.
Rescue work needs someone who can read a trial balance and someone who can read an Apex trigger, on the same call. That combination is the reason these engagements are usually a second attempt rather than a third.
Handover is written into the engagement: what changed, why, and what to watch. A support retainer that never gets smaller is a sign the handover was not done.
Usually the opposite. Most of what is wrong with an inherited Accounting Seed deployment is architecture — a chart of accounts carrying dimensions it was never designed for, ledger separation that does not hold, automation running in the wrong order — and architecture can generally be corrected in place without a blank org. We quote a rebuild only where the assessment shows repair costs more than replacement, and we show the arithmetic rather than asserting it. Starting from a blank org is the last option, not the first.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner, and we implement, configure, remediate and build on Accounting Seed. Accounting Seed licences are bought from Accounting Seed directly — the vendor does not publish public pricing and quotes per company. We deliver the assessment and the remediation; we are not reselling the product.
No. The assessment is priced and delivered as a standalone engagement, and the findings document is yours — what is wrong, what is causing it, and the options with effort and risk against each. Clients take it to their own team, to their existing partner, or to a competitive quote. Scoping it that way is deliberate: an assessment that only makes sense if you buy the follow-on work is not really an assessment.
It does not need to be. Findings are written about the system rather than about the people, because in practice most of these problems come from a scope that never included financial architecture rather than from anyone doing their job badly. Where the original partner is still engaged and capable, handing them a clear findings document is often the cheapest path, and we will say so. What we will not do is soften a finding that has a real consequence for your numbers.
Typically one to two weeks. We need read access to the org — a sandbox refresh is usually enough — a sample of recent periods, and about four to six hours of your finance team's time across the engagement. The most valuable input is not technical: it is a candid walkthrough of the spreadsheets and manual steps people actually use, because every one of those is a requirement the system did not meet.
Yes, and it is a common way these engagements start. Where a team is struggling to get a period closed, we will work the close with them first and treat the assessment as the parallel activity. Stabilising the current period buys the room to fix the cause properly, and the close itself is usually the most informative view of what is actually wrong.
Then the assessment will say so, and it is a conclusion we have reached before. It is genuinely uncommon — the product is capable and the failures are nearly always architectural — but a business whose requirements have moved somewhere the platform does not go is better served by hearing it early. In that case the findings document lays out what would have to be true for the current system to work, and what the alternatives would actually cost, so the decision is yours to make with real numbers.
Bring us the deployment that is live and not working. The first conversation is about what your close actually looks like and where the spreadsheets are — and the assessment is yours to act on however you choose.
Accounting Seed assessment, remediation & managed support
