Partners
Bring the relationship. We bring the reconciliation.
Two shapes of partnership: implementation, where you scope and run the delivery on your own client relationship, and referral, where you make the introduction and stay out of the build. No partner is named on this page — a name is a fact about somebody else, and we publish one only with their written permission.
The two shapes
Which kind of partnership is this?
The difference is who owns the delivery. Everything else — the product, the engines, the evidence, the format library — is identical on both sides.
- Implementation
- You scope the work with your client, map what their ledger posts, configure the entities, the calendars and the approval path, and stay with them after the first module goes live. We supply the engines, the bank connectivity and the format library, and we are on the call the day a bank sends something nobody has seen before.
- Referral
- You know a group whose books and banks do not agree, you make the introduction, and the delivery is ours from there. It suits a relationship that is advisory rather than technical — an audit practice, a corporate finance adviser, a bank’s own transaction banking team — and it suits anyone who would rather not carry an implementation plan.
There is no tier list here and no certification program, because we run neither. The commercial shape is agreed with each partner rather than published, and what a partner may say about the product in public is exactly what this site already says.
What a partner gets
What do you actually get out of it?
Four things. The second is the one that settles the argument in front of your client’s auditor, which is usually where these engagements are won.
- The whole product, with nothing held back
- The same modules, the same engines and the same format library a client would get direct. There is no partner edition and no capability that arrives later for you than for them.
- Evidence you can defend on the client’s behalf
- Every figure opens onto the statement line, journal entry or document it came from. The matching engine keeps the explanations that lost, with their scores, so a decision can be argued from the record instead of asserted.
- The connectivity, so nobody on your team writes a parser
- MT940, CAMT.053, BAI2, CSB43, ISO 20022 messaging, EBICS, SEPA — and whatever else a bank actually sends. A format the library does not read yet is our work, and it does not land on your delivery plan.
- A direct line to the product rather than a reseller desk
- When something in a client’s data is wrong, the conversation goes to whoever can change the engine, not into a queue that turns it into a ticket number.
What you would be implementing
- See the whole product Every module, and the one reality underneath all of them.
- Reconciliation Bank against ledger, with the evidence for every match.
- ERP integrations SAP, Oracle, Dynamics and Navision, read rather than replaced.
- Bank connectivity SWIFT, EBICS, host-to-host and API — however your banks send.
What we expect
What do we ask of a partner?
Four, and they are the four we hold ourselves to. A partner who breaks one is making a claim in our name that neither of us could defend.
- The client’s decisions stay the client’s
- We compute, and we show the working. Which correction gets posted, which threshold matters, what the accounts finally say — those belong to the client’s own accountants and auditors, and nothing said in our name may suggest otherwise.
- A figure is shown with its evidence
- Never rounded to fit a slide, and never a total that quietly leaves out the rows the system could not resolve. Where something is missing, it is named on the surface, with what is missing and why.
- You tell us what the bank actually sends
- A real file beats a specification every time. When something arrives that the library reads badly, we want the bytes rather than a description of them.
- No claim about the product that this site does not make
- No certification we do not hold, no named customer without written permission on file, no number nobody can source. If it is not written here, it is not ours to say.
None of that is unusual in a services relationship. It is written down because the product’s whole argument is that a figure can be defended, and a partner presenting that figure is presenting the argument with it.
The questions we get
What partners ask before the first call.
- 01Is there a partner tier or a certification program?
- No. There is no bronze, silver and gold ladder and no exam, because we run neither. The relationship is scoped per partner, and what you may say about the product publicly is exactly what this site says.
- 02Who owns the client relationship?
- On an implementation, you do: the scope, the delivery and the ongoing work are yours. On a referral, the delivery is ours from the introduction onward. Either way the client’s data, approvals and bank mandates stay the client’s.
- 03What does an implementation partner actually do?
- Scope the group, map what the ledger posts, configure the entities, the calendars and the approval path, and reconcile the history with the client before any module is switched on. The bank channels and the file formats are our side of the work.
- 04Do you work with ERP practices?
- Yes, and the ledger is where that knowledge pays. Most of what makes a group reconciliation hard sits on the ERP side — how intercompany is posted, how a clearing account is booked, what the extract actually contains. A practice that already knows a client’s ledger removes the slowest part of the work.
- 05How do we start?
- Write and say which shape you are after, which groups you have in mind and what you already run for them. The first conversation is about whether those groups have the shape this product is built around.
Bring us a group whose books and banks disagree.
One conversation is enough to work out whether this is an implementation you run or an introduction you make.
No tier to join, and nothing to sign before the first call.