Rewizor nexo and Sfera: the accounting integration you mostly should not build

The Program Where the Automation Already Shipped

Sixth guide in this series on integrating Polish ERP systems, and the first one where my honest advice is to write less code than you planned.

The other five followed the same shape. A client runs Subiekt nexo, or enova365, or Optima, something outside the ERP needs to read or write, and off you go: get a connection, learn an object model, build. Rewizor nexo breaks the shape. The thing people most often ask a developer to build into it is already in the box — switched off, and documented.

Two features do the work. The first sits in the PRO feature list: rozbudowane schematy dekretacji, których wykonanie można warunkować od dowolnej cechy dokumentu źródłowego — posting schemas whose execution can be conditioned on any attribute of the source document. The second arrived in InsERT nexo 41.0.0: an automaton, configured in Ewidencje dodatkowe – Automatyzacja, that fires Po zapisaniu obiektu and performs the action Dekretuj automatycznie.

Put those two together and you have a rules engine that posts documents as they arrive, with conditions attached. Which is what a client means nine times out of ten when they ask whether their accounting can be automated.

What a Posting Schema Actually Is

Let me be precise here, because dekretacja gets thrown around loosely and developers arriving from other stacks tend to picture something simpler than it is.

A schema lives in the Dekretacja dokumentów module, on the Schematy dekretacji tab. Two of its settings carry more weight than everything else put together. Warunek wyboru decides which documents the schema applies to. Kolejność decides which schema wins when more than one could apply. The rest — accounts, amounts, splits — is the part people picture when they hear the word schema, and it is the part that almost never causes trouble.

The trouble sits in those two fields. A schema that posts perfectly but selects the wrong documents produces confident, consistent, wrong entries, at volume, for months. And since ordering is a single integer across a set of schemas that only ever grows, the twelfth schema somebody adds is the one that quietly changes what the fourth one does.

So when you are handed an installation where "the automatic posting stopped being reliable", export the conditions and the ordering first. Not the account mappings. I have never once found the problem in the account mappings.

The Number Nobody Measures

Before any of this, one measurement. It is cheap enough that there is no excuse for skipping it, and almost everybody skips it.

The auto-posting rate. Take one closed month and split its documents three ways:

1. Posted by a schema and never touched again.
2. Posted by a schema and then corrected by a person.
3. Posted entirely by hand.

Ask an office how automated it is and you get the first number back. It is the least useful of the three. The one that decides whether there is a project here is the second — and almost nobody tracks it, for a structural reason. Once a corrected decree sits in the books, it looks exactly like a manual one. The correction leaves no mark on the thing it corrected.

That middle bucket is the specification you are missing. Every correction in it is a person applying a rule that exists and was never written down. This supplier's freight goes to a different account from that supplier's freight. This contractor's invoices need splitting by cost centre. This one is on a different VAT transaction than its document type suggests. Collect three months of them and you are not gathering requirements any more — you are reading them.

On a portfolio of forty clients this is an afternoon of work, and it routinely changes the conversation. I have watched an office that described itself as "maybe thirty percent automated" discover that schemas were touching nearly seventy percent of documents, and that half of those were being silently corrected afterwards. Those are two very different problems. Only one of them gets solved by writing anything.

The Fix Is Usually Upstream, Not in Rewizor

Now the sentence from the PRO list that decides where you actually do the work. Schemas can be conditioned on any attribute of the source document. Read it backwards: a schema can only ever be as specific as the document it reads.

Say an office is correcting purchase invoices by hand because freight from one supplier belongs somewhere different. The schema cannot fix that unless something on the document tells the two cases apart. Usually nothing does. The document says what was bought and from whom; the distinction lives in a person's head.

So the work moves out of the accounting program and into whatever produced the document. In an InsERT estate that normally means pola własne on the Subiekt side, or a dictionary field on the contractor record, added for no reason other than giving the schema something to test. Same finding as the custom-fields trap in enova365, approached from the opposite direction: there, custom fields were the hazard nobody warned the integrator about; here, they are the missing input that makes automation possible at all.

Two consequences worth saying out loud to a client. First, the cheapest improvement to their posting automation may be a five-minute configuration change in a completely different program. Second, if their documents arrive from their clients' systems rather than their own — the normal case for an accounting office, which I wrote about in the six-ERP problem — the attribute you need may not be obtainable at any price. The honest answer then is that those documents stay manual, and saying so early is cheaper than discovering it in week six.

Withdraw and Post Again Is the Most Dangerous Setting in the Line

The automaton has an option for documents already recorded in the books: Wycofaj i dekretuj ponownie. Withdraw and post again.

It exists for a good reason. Without it, an automaton that meets an already-posted document either fails or does nothing, and in a nightly job both are worse than they sound. With it, the automaton becomes close to idempotent — exactly what you want from something running unattended overnight.

It is also the single setting most likely to destroy somebody's work, because it cannot see intent. A decree an accountant corrected by hand at four o'clock and a decree nobody has ever opened are the same object to it. Point it at a scope wider than you meant and it reverses a human decision with nothing to show for it. No error. No log entry anyone will read. Just a decree that is subtly different from the one somebody thought they had fixed.

The rule: automation may never re-post a document a human touched after it was first posted. Mark those, exclude them, move on. It costs you one condition. Get this wrong in an open period and you have an argument; get it wrong in a closed one and you have a correction somebody has to explain to a client, which is the kind of thing I had in mind when I wrote about what an agent cannot do with JPK_V7.

It is also the clearest illustration I have of a point from the liability article: permission levels are not fixed per company. In the CRM I argued the opposite of caution — creating an activity in Gestor is the cheapest write in the entire InsERT estate, because a wrong one costs fifteen seconds to delete. The same permission level in the ledger is nothing like the same risk. Rank permissions by what a mistake costs to undo, not by the verb.

OCR Gives You Fields. It Does Not Give You an Account.

Accounting offices running Rewizor usually take documents in through Portal Dokumentów. Its OCR reads the document number, the date, the contractor and the VAT table amounts, then carries them into the entry being added. It works. It solves a real cost: retyping.

What it cannot do is supply the account. The account is a function of what was bought and why — and that is very often not written on the invoice at all. "Usługi doradcze" from a company you paid three times last year could sit in several different places, depending on decisions nobody ever printed.

So the automation chain has a hole in the middle. OCR handles the reading, schemas handle the posting, and between them sits classification, which is neither. Classification means looking at the supplier, the wording, what this office decided for this contractor last quarter, and what similar documents got. Judgement from context and precedent. Which happens to be what a language model is genuinely good at, as opposed to the arithmetic tasks people keep pointing them at.

That is where a model belongs in a Rewizor installation, and the undo cost fixes its shape: it proposes an account and a schema, a person confirms, and the confirmation trains the next proposal. It never posts. A wrong proposal costs a click. A wrong entry in a closed period costs an afternoon and a phone call. The gap between those two numbers is the entire design.

What I Would Build First

Nothing, for the first week.

Measure the auto-posting rate and pull three months of corrections made to auto-posted decrees. Sort them into two piles: corrections a rule could have made (same supplier, same account, every time), and corrections that needed a person who knew something the document did not say. That ratio tells you what kind of project this is. It is the same diagnostic I proposed for JPK_V7 corrections — the data either could have caught it or it could not, and everything else follows from that split.

Then, in order. Fix the schema conditions that the corrections have just specified for you. Add the missing attribute upstream wherever a condition needs one. Only after that, build the classifier for whatever is left, and ship it as a proposal queue a person works through — with the auto-posting rate measured again a month later, so you can prove the thing actually moved. And if it did not move, you find that out from the same cheap measurement rather than from an argument about invoices.

Sfera for Rewizor comes last, if it comes at all, and only for what it is genuinely for: custom reports over posted data, extension points, feeding a system that lives outside the InsERT estate entirely. If you do reach for it, the licence rule from the rest of this series applies unchanged — it belongs to Rewizor nexo PRO specifically, and owning Subiekt nexo PRO buys you nothing here. The comparison in the integrator's API guide covers where it sits relative to the alternatives.

Wondering whether your posting rules are the constraint, or whether the corrections are telling you something else? Get in touch. One closed month and a list of corrections is enough to tell which — and it is a far shorter conversation than a specification.