Every Accounting Seed deployment eventually meets a requirement configuration cannot reach — an allocation rule, a bespoke invoice format, an API to a system the business runs on. The answer is not to modify the managed package, and it is not to give up on the requirement. Twopir Consulting writes Apex, Lightning Web Components and integrations against the product's supported objects, tested and bulk-safe. Extend the ledger without owning a fork of it.
All four figures are from a single documented Accounting Seed engagement with a 150-employee US client — not a blended average across clients. Read the full case study.
Twopir Consulting has delivered Salesforce and finance systems for 500+ organizations across 12+ years — including custom Apex and Lightning Web Component development on top of Salesforce-native finance systems.
Systems We Build On
Custom work on a managed package fails in predictable ways, and none of them are about the requirement being wrong. They are about where the code was put, how much data it was tested against, and who was expected to maintain it. Every failure below is one we have been called in to unwind.
Work built against unsupported internals, or worse inside the package itself, means every vendor release becomes a project. The org ends up several versions behind and the gap widens each quarter.
Logic written record by record hits governor limits the first time a real billing run goes through it. The failure lands at month end, in production, on the busiest day of the finance calendar.
A Flow, a trigger and a scheduled job each touch the same records with no agreed order of operations. The symptom is a number that is right most of the time, which is worse than one that is always wrong.
Assertions that assert nothing pass a deployment and catch no regressions. The first real proof the change was safe arrives when finance notices the ledger is wrong.
The developer who built the allocation rule has left, the requirement was never documented, and the code is now something the team is afraid to change. It quietly becomes a constraint on the business.
A payment or usage feed stops posting, with no retry, no alert and no failure record. The gap is discovered during a reconciliation weeks later, and the recovery is manual.
Accounting Seed is an accounting platform built natively on the Salesforce platform, delivered as a managed package. It provides general ledger, accounts receivable, accounts payable, billing and invoicing, project accounting, financial reporting and online payment processing on the same platform as the customer records. Because it is a managed package, its internals are not editable by the subscriber — which is a feature, not a limitation: it is what allows the vendor to ship upgrades that do not break your org. Salesforce's own packaging documentation explains the constraint; this page covers how we build inside it.
So custom development on Accounting Seed means building alongside the package rather than inside it: Apex triggers and asynchronous jobs on supported objects, Lightning Web Components in the finance UI, and integrations through documented APIs. The discipline that matters is bulk-safety and testability, because this code runs against a general ledger at month end. Everything we write is deployed with real assertions and handed over with the design decisions documented, so the next person to touch it is not guessing.
The supported surface. This is what custom work is allowed to build against.
The service. Design first, then code that a finance team can run a month end on.
The operating change — mostly things that stop happening.
The most useful thing a development partner can tell you is which of your requirements does not need them. We exhaust the declarative surface first — it is cheaper, upgrade-safe and maintainable by your own admin — and write code only past the line below.
| Engagement | What it covers | Where the boundary sits |
|---|---|---|
| Configure first | Everything achievable declaratively: rate tables, billing formats and schedules, approval routing, validation, Flow automation, page layouts, permission sets, reports and dashboards."Accounting Seed configuration" | This tier is the default answer, and a good partner will talk you out of code here. Declarative work stays upgrade-safe and your admin can maintain it without a release cycle. |
| Build on | Apex and LWC where the configuration surface runs out: allocation and accrual logic, revenue and fee-split rules, interest and late-fee automation, bespoke document formats, bulk finance UI, complex validation across objects."custom Accounting Seed development" | Starts the moment a requirement needs Apex, a Lightning Web Component or an API. Written against supported objects, bulk-safe, with real test assertions — never by modifying the managed package. |
| Integrate | Inbound and outbound interfaces: payment and usage feeds, warehouse and EDI, payroll, corporate ERP and group ledgers, plus the error handling, retry and alerting around them."Accounting Seed API integration" | Ends at the contract with the other system. Where the other side is a Twopir build too, one team owns both halves; where it is not, we own the mapping and the failure behaviour on our side. |
| Remediate | Fixing custom work already in the org: unpicking logic that blocks upgrades, bulkifying what fails at volume, replacing coverage-only tests, and documenting what nobody wrote down."Accounting Seed customization not working" | Begins with a code and org assessment, not a rewrite. Most inherited custom work can be corrected in place; a rebuild is the last option rather than the first. |
If the problem is the deployment rather than the code, start with QuickBooks to Accounting Seed Migration instead — the assessment there covers ledger structure as well as customisation.
These are the custom modules that come up repeatedly on Accounting Seed engagements. They are listed as the requirements they are, because every one of them starts as a business rule that configuration could not express.
Fee splits, commission accruals, functional expense allocation and intercompany distribution calculated as the revenue is recognised, bulk-safe across a full month's transactions.
Automated calculation against each client's own terms and grace periods, with the escalation sequence running as scheduled Apex rather than as a reminder in somebody's calendar.
Document generation matching a client's, funder's or trading partner's required layout, produced from ledger data rather than assembled from an export.
Percentage of completion, milestone, usage and ramp treatments implemented as scheduled logic against the contract line, so the deferred balance is traceable rather than adjusted.
Bulk actions the standard UI does not offer — mass billing review, batch cash application, exception queues — built as LWC so the finance team works in one screen instead of five.
Inbound and outbound interfaces with idempotency, retry, dead-letter capture and alerting, so a feed that stops posting raises something visible instead of a silent gap.
Month-end jobs written as Batch or Queueable Apex with chunking and checkpointing, so a billing run that grew tenfold still completes inside its window.
Tests with assertions that would actually fail if the ledger logic broke, plus the deployment path that runs them — the part that makes every later change cheaper.
Every finance integration has two specifications: what moves when it works, and what happens when it does not. The second one is the reason these builds are quoted as engineering rather than as connector configuration.
| Systems | Business purpose | What moves, and which way |
|---|---|---|
| Salesforce · Accounting Seed | Understand why most requests that arrive as "integrate our CRM with accounting" are not integration work at all. | No integration Native — same platform, same database. Custom work here is Apex and Flow against shared objects, not an interface. Anyone quoting a connector between these two is quoting the wrong thing. |
| Payment gateways & processors | Post authorisations, settlements and failures against invoices and cash receipts without a manual application step. | Payments → ledger Webhook and polling ingestion with idempotency keys, retry and a dead-letter queue. A failed post raises an exception record, never a silent gap. |
| Usage, metering & product telemetry | Turn what the customer consumed into a billable line on the right subscription, at the right rate. | Product → ledger Aggregated usage loads via Bulk or Composite API, rated in Apex against contract tiers. Reprocessing is safe — a re-run does not double-bill. |
| Payroll, expense & time systems | Get labour cost and reimbursable expense onto the right dimensions, which is where allocation usually goes wrong. | Source → ledger Journals and claims post against the agreed dimension set, with a reconciliation record per batch. Consumed by finance, who can see what did and did not land. |
| Warehouse · EDI · trading partners | Keep stock and order state consistent between systems that both believe they are authoritative. | Bi-directional Orders, acknowledgements, shipments and invoices exchange on the partner's schedule, with sequence and duplicate handling. Conflicts surface as exceptions rather than as overwrites. |
| Corporate ERP · group ledger | Move summarised financial position to a parent system on a reporting calendar you do not control. | Bi-directional Journal summaries and intercompany entries move both ways on an agreed cut, with a period lock so a late correction cannot silently reopen a closed period. Consumed by group finance. |
Integration work that spans more than Accounting Seed sits inside our Salesforce integration; quote-to-cash specifically is covered in CPQ to Accounting Seed.
Most bad custom work on a finance system is not badly written — it is precisely built to a requirement nobody stated properly. We write the rule down, in finance language, and get it agreed before anyone opens a class.
We establish what the rule actually is and check whether the declarative surface can already express it. A meaningful share of requests end here, which is the cheapest possible outcome for you. Typically 3–5 days.
The rule written down in finance language with its edge cases, then the technical design: which objects, which trigger context, synchronous or asynchronous, expected volumes, and the failure behaviour. Agreed with your admin or architect before code exists. Typically 1 week.
Bulk-safe Apex and Lightning Web Components against supported objects, with tests that assert the ledger outcome rather than the coverage number. Volume is simulated at the scale your month end actually runs at. Typically 2–6 weeks depending on scope.
Finance runs the real process — a billing run, a close, an allocation — against a sandbox with realistic volume. Governor limits and ordering conflicts surface here rather than in production.
Deployment through your pipeline, monitoring on the first live run, then written handover: what the rule is, why it was built this way, and what to check if it stops working. Your team should be able to maintain it without us.
Durations are typical ranges per module and are confirmed after the design phase. Where a requirement turns out to be configurable, we say so and stop — that outcome is a successful Phase 01, not a lost sale.
Both are published Twopir Consulting engagements. The first is the most directly relevant evidence on this page: seventeen custom automation modules delivered on Accounting Seed for one client, including the interest calculation that removed manual tracking entirely. Every figure is scoped to the business it was measured at.
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.
Seventeen custom automation modules built on Accounting Seed — including automated interest calculation and mass billing.
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.
Custom integration across Salesforce, AWS and QuickBooks for end-to-end work-to-cash operations.
Custom work on a general ledger is not ordinary Salesforce development. It runs at month end, against real money, in front of an auditor. The difference shows in what gets written down before the first class is created.
Phase 01 exists to find the requirements that configuration already covers. Declarative work is cheaper, upgrade-safe and maintainable by your own admin, and a partner who never reaches that conclusion is not looking for it.
Everything is written against supported objects and documented interfaces. That is what keeps the vendor's upgrade path intact, and it is the single most common thing we are called in to unwind.
Logic is written for a full month's transaction volume from the first line, and tested against it. Governor limits found in UAT are cheap; found during a live billing run they are not.
A test that passes while the balance is wrong has cost you money to write. Ours assert the financial outcome, which is what makes the next change safe to deploy.
The same people who designed your chart of accounts write the Apex. No second vendor, no handoff, and no argument about whether a rule is a configuration or a development problem.
Not if it is written correctly. Accounting Seed ships as a managed package, so its internals are not editable by a subscriber — which is the protection, not the problem. We build alongside it: Apex on supported objects, Lightning Web Components in the finance UI, and integrations through documented interfaces. Work built that way survives vendor releases. Work built against unsupported internals does not, and unpicking it is a recurring part of our remediation practice.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner, and we implement, configure 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 development work; we are not reselling the product.
You do. It is deployed into your org, in your repository if you have one, and handed over with the design decisions documented — what the rule is, why it was built this way, and what to check if it stops working. If you have an in-house admin or developer, they are in the design review rather than being handed a finished black box. A build your own team cannot maintain is a build we have done badly.
Yes, and it is a common arrangement. Typically the in-house team owns declarative configuration and day-to-day administration while we take the Apex, the integrations and the finance-specific logic, working in your branching and deployment process. What matters is agreeing the order of operations across Flow, triggers and scheduled jobs up front, because that boundary — not the division of labour — is where mixed-team builds actually go wrong.
Yes, and it starts with an assessment rather than a rewrite. We review the code and the org for the three things that usually matter: whether anything is built against unsupported internals or blocks upgrades, whether the logic is bulk-safe at your real transaction volume, and whether the tests would fail if the ledger outcome broke. Most inherited work can be corrected in place. Where a rebuild is genuinely cheaper than the repair, we show the reasoning rather than asserting it.
Typical modules run two to six weeks from signed-off design to production, with the requirement review and technical design taking one to two weeks before that. What moves the number is rarely the code: it is how clearly the business rule is defined and how many edge cases emerge when it is written down properly. That is why the design phase is separate and signed off — an estimate given before the rule exists is a guess with a number attached.
As part of the requirement, not as an afterthought. Every interface we build is idempotent so a re-run cannot double-post, retries transient failures with backoff, captures anything it cannot process as an exception record, and raises an alert a person actually receives. A finance feed that stops silently is worse than one that fails loudly, because the gap is found weeks later during a reconciliation and the recovery is manual.
Bring us the rule that configuration could not express. The first conversation is about the requirement and its edge cases — and sometimes it ends with us telling you it can be configured.
Apex, Lightning Web Components & integrations on Accounting Seed
