You advise. We build. Your client stays yours. Xylity works as the finance automation delivery partner behind CFO advisory practices, fractional CFO firms and accounting firms that design finance stacks for their clients but do not build them. You keep the relationship, the design authority and the invoice. We supply the engineering.
Non-solicitation is in the agreement. We do not approach your client for work outside the scope you bring us
We recommend an approach and justify it. You approve it before anything is built
White-label under your name, named subcontractor, or a direct introduction, set per engagement
A scoping call within days of you asking, and a build start inside two weeks of sign-off
This is the moment the advisory engagement either extends or leaks. There are three usual answers and only one of them keeps you in the room.
You lose sight of how your own design gets implemented. The implementer talks directly to your client about scope and everything adjacent to it. When the build is wrong, the client associates it with your recommendation, and the next advisory conversation happens without you.
Keeps your bench free. Costs you the relationship.
Integration engineers are a different hire from accountants and a different utilisation curve. Demand arrives per client, not per quarter, so the bench is either idle or short. One engineer becomes a single point of failure on a client's ledger.
Gives you control. Costs you a function you did not plan to run.
Capacity appears when the client signs and stands down when the build is done. You keep the design authority and the relationship. The build follows a documented standard you can show the client's IT reviewer.
Only works if the partner behaves like one. That is the rest of this page.
Advisory firms do not lose clients to delivery partners because the build went badly. They lose them because the partner became the person the client called.
| Decision | Who holds it | How it works in practice |
|---|---|---|
| The client relationship and the contract | You | You contract with the client. We contract with you. The client may never need to know our name, and in most engagements they do not |
| Scope and solution design | You | Your design is the input. If we think part of it will not work we tell you privately, with the reason and an alternative, before anyone builds anything |
| Platform and vendor selection | You | We have no reseller margin on any finance platform and no certification to protect. The recommendation you have already made is the one we build to |
| Build approach: API or RPA, per step | We recommend, you approve | The interface assessment is a written deliverable. You see the call and the reasoning for each step, and sign it off before build starts |
| Who speaks to the client, and as whom | You, per engagement | White-label, named subcontractor, or direct introduction. Set at the start of each engagement and changeable between them |
| Day-to-day build decisions inside the design | Us | Field mapping, error handling detail, retry policy, test data. We do not bring these to you unless they change the design or the control model |
| Go-live sign-off | You and the client | After a parallel run of at least one full close, with every difference explained in writing. We do not declare our own work finished |
| Support after go-live | Agreed per engagement | Routed through you, or direct with your written consent. Never direct by default, and never a route into an unrelated conversation |
Non-solicitation, stated plainly. We do not approach your client for work outside the scope you bring us, not during the engagement and not after it ends. If your client approaches us directly, we tell you before we reply. This is contractual, and we will sign yours rather than insist on ours.
Six stages. The first two happen before you commit anything, and before you have to give the client a timeline.
You describe the client environment, the design you have recommended and the constraint you are working inside: budget, close calendar, an auditor's finding, a migration already under way. No client contact at this stage.
What each system in scope actually exposes: which API, which version, authentication, throttling, sandbox availability. The API-or-RPA call made for every step with the reasoning attached.
We price the build against the assessment rather than a guess. You decide your own margin and how the work is presented. We are not in that conversation unless you want us in it.
Development on a non-production instance with representative data. The exception path and the run reconciliation are built in the same sprint as the main flow. You get a weekly written update whatever cadence the client sees.
The automation runs alongside the manual process for at least one full close. Both outputs compared line by line, every difference explained before anything is switched off.
Runbook, service account permission specification, change process and escalation path. Support terms agreed in writing, routed through you unless you say otherwise.
The engagement shapes we see most often from CFO advisory and accounting practices.
The client runs an operational or billing system that does not talk to the general ledger, so someone exports and re-keys every month. Posting rules, mapping, period control and a tie-out report that proves the run.
Sage Intacct integration →The client takes card payments and the payouts never match the transactions. Three-way matching across source transactions, processor payouts and bank lines, with an exception queue for what rules cannot settle.
Reconciliation detail →Capture, coding, three-way match against purchase order and receipt, threshold-based approval routing and posting, with the exception path designed first, because that is where the work actually sits.
Finance process automation →A checklist with real dependencies and status, recurring and accrual journals generated from source data, variance packs assembled and distributed. The judgement stays with the client's finance team.
Reporting automation →Vendor and customer master consolidation during a system change, with duplicate detection, validation rules and an approval step. Bank detail changes always route to a person with dual approval.
ERP consulting →For practices running several client builds at once: integration and automation engineers working inside your delivery process and under your direction, rather than a project at a time.
Scale Your Business Applications Team →Suppliers change invoice layouts, banks add fields, a platform ships a breaking release. The question your client will ask you, not us, is who deals with that.
A runbook written for the client's team rather than for an engineer who already knows the system. The service account permission specification, so the next access review knows what it should have. The change process, the control evidence pack, and architecture documentation at a level the client's IT reviewer will accept.
The client raises with your team, you raise with us. Most common, and it keeps your firm in the relationship. Response commitments are agreed per engagement and written down rather than assumed.
The default.
Direct contact is faster for an urgent break, scoped to the automation we built and with you copied on everything, and only with your consent. Or the client's own team takes it on: the documentation is written so that is a real option, not a theoretical one.
Both set at handover, in writing.
Same model, different page.
IT services companies between 20 and 1,000 people usually come to us for delivery capacity across a wider set of domains than finance, and often for a named specialist rather than a scoped build. Our page for IT services companies covers that, along with how we work and why our matching is consulting-led. Across the network our average to a first curated profile is 4.3 days with a 92% first-match acceptance rate.
For finance automation specifically, the two pages that matter most to a technical reviewer are how we build finance automations, written for IT and security, and finance process automation services, which is the page you can send a client. Partner terms sit on become a partner, and what partners and clients say carries references.
What advisory and accounting firms ask before the first client engagement.
No, and it is contractual rather than a promise on a web page. We do not approach your client for work outside the scope you bring us, during the engagement or after it ends. If your client approaches us directly, we tell you before we reply. We will sign your non-solicitation agreement rather than insisting on our own.
Yes, and it is set per engagement rather than per firm. The three options are white-label under your name with no client-facing mention of Xylity, named subcontractor where the client knows who is building, and a direct introduction where you prefer to step back from delivery. Most advisory firms use white-label for the first engagement and relax it once the client relationship is settled.
You hold the design authority, so your call stands. What we will do is put the disagreement in writing to you, privately and never to the client, with the reason and the risk we see. If you still want it built your way and it is safe to build, we build it. If we think it will produce a wrong number or break a control, we will say that we cannot build it, and explain why in terms you can take to the client yourself.
The scoping call happens within a few days of you asking, and a scoped finance automation build usually starts within two weeks of the interface assessment being signed off. The assessment itself is the gating item, because pricing a build before you know what the systems expose is guesswork. Where you need a named specialist rather than a scoped build, our network average to a first curated profile is 4.3 days.
No. A finished design makes the first conversation faster, but plenty of engagements start with a client problem and a rough direction. What we will not do is design the finance operating model for your client around you. That is your work, and it is the part your client is paying you for. We will tell you what is technically possible and what each option costs to build, which is usually the input your design is missing.
Every engagement goes through a parallel run of at least one full close before anything manual is switched off, specifically so a problem is found while the fallback is still running. After go-live, support is routed through you unless you have consented to direct contact, and the terms are written into the engagement rather than assumed. The handover pack is written so the client's own team can operate and change the automation without us.
Start with a scoping call. You describe the client environment and the design you have recommended, and we tell you honestly whether it is a two-week job or a two-month one. No client contact at that stage, and no obligation to proceed.
Tell us what you need. We will send curated profiles within 4 days.