Accounting integration turns on ownership: whoever holds the record settles which way the transfer runs and where a correction lands. With the source on your side, your system produces the period record and hands it to the program that keeps the books, which never writes back. In Pilatesco a package sale produces a ledger entry, while the classes taken later produce none, because usage is read from the calendar.
The accounting program may not be yours
Most businesses picture a module when they say integration. Something bolted onto the system they already own, with a settings page and a switch on it. If somebody else owns the ledger, there is no module to bolt on. When the ledger is kept in your accountant’s program, integrating with it means building a handover point between two records that belong to two different owners.
The quickest way to see that is to look at where records sit today. AlgoCar workshop management software is our own product, and the arrangement we started from looked like this: the order opened for a car lived in one program, the store holding the parts consumed against it in a second, the invoice raised at the end in a third. Three programs mean three owners of three records. Pulling that chain into one system is our work, and it is what we are still building.
One of those owners cannot be pulled in. A program you do not own keeps running on its own calendar whatever your system does, and it will still be there next period, holding the books. When something cannot be absorbed, the only structure you can put in its place is a handover point.
That distinction separates two jobs which get discussed as if they were one. We have written before about the difference between an integration and a setup decision: an integration joins systems that already exist and every connection carries its own maintenance, while a setup decision arranges for the records to be created in the same place to begin with and leaves nothing to join. For records you can bring inside, the setup decision is the right answer. For the ledger it is unavailable, because you are not the one deciding where that record is created. What remains is a seam.
It is worth narrowing what actually crosses that seam. Not a single document, but a ledger-shaped record: a period total, an account movement, a receipt. The document itself is a different subject. Where its number comes from, which type it is issued as and how it reaches the tax authority are covered in our article on connecting software to e-invoicing. Here the subject is the ledger rather than the document.
A counter-case belongs at the front. If your own accounting staff keep the books in a program you own, there are not two owners in the picture: the question becomes a setup question, and the work described below never reaches you.
Which records are created on which side
Before asking where the handover point goes, you have to sort what is being handed over. Scope comes out of that sorting and so does price. Without it, a request to integrate with accounting has no shape anyone can quote against.
There are two columns. The first holds operational records: the work itself, created in your system and staying there. In AlgoCar an order is opened against a vehicle and the parts consumed are written onto that order. Both of them are the operation. In the Pilatesco booking and package system the same column holds package sales, bookings and the remaining class entitlement. That entitlement rides on the customer’s own record rather than in a second book kept alongside it. It is live today, and support and updates carry on.
The second column holds ledger-shaped records: things derived from the first column that have a line in the books. An invoice is the familiar member. In AlgoCar it comes off the work order record; in Pilatesco it appears at the moment the package is sold. Account movements, receipts and period totals belong to the same column. Your system does not hold those. It holds the operational records they are derived from. What that distinction means in practice: holding a record means the place it is created and the place it is corrected both sit with you.
The instructive part of the sorting is its negative side. Not every operational record has a counterpart in the books. In Pilatesco the classes taken across the following weeks are read from the calendar and produce no ledger-shaped record at all. That narrows scope immediately, and in a useful direction: the list of records going across is always shorter than the list of records you keep.
There is one more boundary, and the documented version of it sits in AlgoCar. The operational side and the commercial side share the system the service record lives in, so what a job spent and what it returned settle in one place. What settles inside is the commercial record of the work. Which program holds the statutory books sits outside that record, as a separate question.
The counter-case marks the lower edge of the sorting. If a record type is never created in your system, nothing ledger-shaped can be derived from it. In the arrangement Pilatesco started from, the remaining class entitlement was tracked outside the calendar, in a book. Nothing derives from a record that does not exist, so the first job is to bring it inside.
How one-way derivation works
Direction gets discussed as a preference. It is not. Direction is your decision about whether the other side may write into your record, and it is taken while the data model is being drawn. In a one-way setup the source record stays in your system, a ledger-shaped period record is derived from it and handed to the accountant’s program, and the receiving side never writes back to the source.
Direction is easiest to read inside a single system. In AlgoCar stock falls the moment a part is written onto an order, and nothing is typed into the store a second time. The order is the source and the stock movement is read from it. The reverse path is never opened: an edit made on the store screen does not rewrite the order. We set out that split between a source record and a derived one in our architecture-first article on source and derived records.
Derivation across a span behaves the same way. In Pilatesco the usage spread over weeks is read from calendar records, and no separate table is kept for the remaining entitlement. The package sale and the classes taken are both read from one customer record. A derived value does not get to sit beside its source as a second version of the truth.
Apply that rule to the seam and one-way handover falls out of it. The source record stays with you. The ledger-shaped period record is derived from it. The derived record moves outward to the side that keeps the books, and that side stands there as a recipient. Honesty matters at this point: what you are reading is a construction rule, not a case study. No project in our portfolio has a documented period record handed to an accountant, and we do not present the handover as a client outcome.
The shape of the handover has to stay generic for the same reason. The period record is produced by your system, comes out in a form the other side can read, and carries the fact that it went across as a status on the record itself. No separate list of pending items gets opened, because a hand-maintained second list soon disagrees with the first.
The counter-case draws a hard line. Derivation only works if the source record is created inside your system. If the source is created in an old program you cannot change, no period record can be derived from it; it can only be carried across as a second act of data entry. At that point the work is not building a transfer. It is reading that system first and changing where the record is created. That is the subject of the consulting work of reading an existing system first, not the subject of this article.
Why two-way integration turns into a permanent reconciliation job
Two-way tends to be presented as the fuller connection: both sides can write, both stay current. The mechanism says the opposite. In a two-way setup the same record can be written in two ledgers with two owners, and no shared place exists for the rule that says which change wins.
The underlying problem is not new, and we have a solved version of it inside one system. One of the difficulties we ran into while building AlgoKlima service management software was that a single record could be edited from the office panel and from the field app without either knowing what the other had done. We close that by attaching both interfaces to the same system and by putting the rule that decides which change survives into code, where it runs as soon as connectivity returns. The queue itself is described in our offline-first field app article on how conflicts are resolved. What matters here is not the shape of the queue but who holds the rule.
The solution has two conditions: there has to be one record in the middle, and the rule sitting on that record has to be yours.
When the far side of the seam is not your system, both conditions fall away. The same record lives twice, in two separate ledgers, and there is no shared codebase for the rule to live in. Which figure is valid stops being something you build once. It gets settled again every period, and the thing settling it is not software but a person with both sides open in front of them. Reconciliation turns into permanent work exactly there, and the convenience two-way appeared to promise turns inside out at the same point.
The limit of software shows up in the same place. Conflict resolution makes the record singular; it does not make the decision singular. Which figure two sets of books agree to call correct is a judgement, and code only supplies the place where that judgement gets written down.
The counter-case matters, because the rule does not forbid two-way traffic. When both faces of the system are yours, two-way is legitimate and the rule is written in code; that is what we do in AlgoKlima. The problem is not two-way. It is two-way with no owner.
How often the transfer runs
Frequency usually gets answered out of anxiety: the more often we send, the safer we must be. Frequency follows the record type instead. Operational events happen continuously while ledger entries belong to a period, so what the accounting program receives is the period record.
The operational side runs at one speed. In AlgoCar stock falls as the part is written onto the order. In Pilatesco a class entitlement comes off the package as the booking is written into the calendar. Both run at the speed of the operation, because both are the operation.
Ledger-shaped records are not created at that speed. In Pilatesco the invoice appears once, at the moment the package is sold, and the classes used over the following weeks are read from the calendar without creating a new accounting record. Why the moment of sale and the span of usage are carried separately is set out in our article separating appointments from service requests. The consequence here fits in one sentence: the seam does not have to run at operational speed.
Two speeds can sit side by side inside one system. In AlgoCar a stock movement is created per part while an invoice is created per work order. One chain, two frequencies, and a real question about which of them the outward seam should follow.
When the two sides are kept apart, the meeting point drifts to the close of the month on its own. In the workshop arrangement AlgoCar started from, what a job had spent and what it had returned were brought face to face only at the month’s close, by hand. That is where you see most clearly that the period is the unit where two sets of books meet. Nobody does it weekly, because the unit belonging to the ledger is the month.
What follows from this is a construction recommendation, not a case. Handing the period record over at period close feeds the ledger in the ledger’s own unit. Sending every event hands the other side records that have no line in their books. The accountant re-sorts each incoming movement, and what you delivered turns out to be work rather than data.
The counter-case comes up often. If your system only keeps operational records and the number of records going to accounting does not strain manual entry, there is no transfer to build. Producing a period report and handing it over is enough, and the maintenance a connection carries can outweigh the work it removes.
What happens when the accountant corrects a record after the handover
This is where the real fear sits. The other side edits a figure in their own program, and the record on your side stays quietly wrong.
In a one-way setup the answer is clean. A period that has gone across is closed on your side; a correction the accountant makes in their own program belongs to their ledger and is never written back to the source. That is not a gap, it is the direction doing its job: open a write-back path and the record acquires a second owner, which drags the problem from the previous section inside your own system.
If the source really is wrong, there is still one route. You make the correction, and you make it as a new record; you do not go back and edit a period that has already gone across. The difference surfaces with the next handover, and both sides keep a trace of what changed and when.
The working version of the principle sits in Pilatesco. A class being cancelled, a customer not turning up and a class being completed each produce their own outcome on the package balance, and which of them returns the entitlement is defined in the rule rather than agreed in a conversation. Nobody edits the balance by hand. A correction is not an overwrite. It is a new record with a rule behind it.
That corrections do not scatter is a consequence of a setup decision. In AlgoCar what a job spent and what it returned close on the same record, so a change made on the order moves both at once. In an arrangement split across two programs the same change would have to be entered twice, and nobody could promise the two stayed identical.
One boundary: correcting a filed document itself, cancelling it or objecting to it, is not the subject of this article. What changes there is the document rather than a line in the ledger, and the rules for it belong to the e-invoicing article.
The counter-case is the practical part of this section. If the accountant’s correction comes from a genuine error in the source record, the correction still goes into the source from your side, as a new record. Automatic write-back does not get built even then. Build it and you lose the information about which side the error was created on.
Three setups side by side
The table is not a ranking. It puts three setups next to each other and shows, in the last column, the manual work each one leaves inside the business. The column doing the deciding is the second one.
| Setup | Who owns the record | Direction of transfer | Frequency | What an accountant’s correction does | Manual work left inside the business |
|---|---|---|---|---|---|
| No connection: the same record is entered into separate programs one at a time (the arrangement AlgoCar started from) | Each program holds its own record; the order, the store and the invoice have separate owners | None; a person carries the record from program to program | A second entry on every transaction, with the comparison at period close | Your system never sees the correction; the gap surfaces in the period comparison | Entering the same record twice; bringing spend and return face to face at period close |
| One-way derivation: the source stays with you, a ledger-shaped period record is derived and handed over | The operational record originates on your side and never leaves it; the other side holds the ledger form | One way, outward; the receiving side never writes to the source | The ledger-shaped record appears once, at the sale; usage spread over a span creates nothing | It stays in their ledger and does not come back; a change in the source opens a new record | Producing the period record and handing it over |
| Two-way integration: the same record can be written on both sides (the ownerless version, at the seam, of what AlgoKlima solves inside one system) | The same record lives twice in two separate ledgers; there is no shared record in the middle | Two ways | On every change made by either side | The correction is written back to the source; neither program holds the rule that says which version is valid | Reconciliation repeated every period |
The link between the columns runs one way. Once ownership is settled the remaining three follow: one owner, and that owner is you, means the direction points outward, corrections arrive as new records, and the manual work shrinks to producing a period record. Two owners means the direction opens both ways, corrections live separately in two ledgers, and the manual work becomes a reconciliation that returns every period.
Most businesses are sitting on the first row today. Moving to the second is not a settings change; it is a decision about where records are created, taken while the system is being built. The third row looks like an upgrade on the second and, read down the ownership column, is a step back.
The order of questions we ask while building the chain is always the same: which record will be created inside, which one stays outside, and where the handover point with the outside one lands. That is how we build ERP systems where operations, stock and the commercial record close in one chain, and that page also says where the ledger stays.
