The Interface Layer, part 5: how a Romanian company starts

Four chapters described the interface layer: finding the job, handing a seam over, measuring it, and replacing forms. This last chapter is about the practical question a Romanian company asks at the end of all that: with everything the state has required of us in the last few years, where do we begin? It turns out the state answered part of the question without meaning to.

The Romanian starting position

In a short span, Romanian companies were required to send and receive invoices through the national e-invoicing system, to prepare a standardized ledger export for the tax authority, and to declare certain transport movements before they happen. Each mandate landed as cost: downloads and uploads in SPV, declarations typed into portals, a monthly dossier assembled for the accountant, and the seams that all of that added to already-stretched back offices.

Look at the same facts from the other side. Every invoice a company receives now exists as structured XML with a schema. The ledger has a standard machine-readable shape. Transport data is captured in a defined format. For the first time, the raw material of the interface layer, the documents that used to be paper, photos, and PDFs with a hundred layouts, is uniform and machine-readable by law. Companies elsewhere in Europe are heading toward the same position as e-invoicing mandates spread; Romania simply arrived early and abruptly. The pain was real. So is the position.

The seam most companies forget to count

In a large share of Romanian companies the accountant is external, and the accountant is a system. Information crosses that seam every month: invoices photographed and sent on a messaging app, the dossier of originals, questions about what a payment was for, the return trip of entries and declarations. Chapter 1's inventory usually shows this as the widest seam in the company, and it rarely appears on anyone's list because it looks like a relationship rather than a data flow. Count it. The accountant will thank you: they are crossing the same seam from the other side.

Three shapes, three first seams

The small company with an external accountant. The first seam is the one to the accountant. Intake replaces the photos: incoming e-invoices arrive from SPV on their own, receipts and contracts are dropped in as they come, and the monthly dossier assembles itself, complete, categorized, with sources. The accountant receives structure instead of a folder of images, and the questions in both directions drop. Nothing is filed with the authority by the layer; the accountant's declarations remain the accountant's acts.

The mid-size company with finance in-house. The first seam is supplier invoices into the ledger, exactly as chapter 2 laid out, because the input is now structured and the judgment repeats. The second is client status questions answered from operational systems. Transport declarations come third, once the layer has memory of routes, partners, and the rules that govern them.

The accounting firm. The seam is SPV multiplied by the number of clients, and then the client questions. A firm that pulls every client's e-invoices automatically, categorizes them, and prepares each dossier has removed a day of logistics per month per accountant and gained something more valuable: the ability to answer "what did this client buy from that supplier this year" in a sentence. The accountant's expertise, tax, gets the hours back.

The ninety-day plan

Days 1 to 10: the two inventories. The seam inventory from chapter 1 and the forms inventory from chapter 4, made with the people who do the work. Deliverable: two pages, ranked, with the judgment column filled in.

Days 10 to 30: first seam, design, shadow. Pick by chapter 2's five criteria. Write the design document: the seam on the loop, a tier per step, the confirmation rule. Start shadow mode: the system proposes, the person keeps working as before, you compare daily. Deliverable: the baseline and a first per-class precision number.

Days 30 to 60: assisted, memory grows, first numbers. The person works from proposals and corrects. Every correction becomes memory. The weekly one-page review from chapter 3 starts. Deliverable: approval rate per class, the unresolved queue and its age, hours returned against the baseline.

Days 60 to 90: earned autonomy, second seam. Classes with a clean approval record and an undoable failure mode move to sampled autonomy. The second seam enters shadow. Deliverable: a report an owner can read in five minutes: hours returned, escape rate, cost per correct decision, and what comes next.

Ninety days is realistic with one willing owner and a company that keeps the review cadence. It stretches when the review is skipped, not when the technology is slow.

What to have in place before day one

• An owner per seam. The person who does it today, willing, with the time to review daily during shadow.
• Access to the documents. SPV authorization for the company's certificate holder, a folder or inbox where the rest already lands.
• The accountant in the loop. Shown the audit trail early, because their trust in what the layer produces decides whether the monthly dossier is accepted or re-done.
• The confirmation rule, written. What waits for a person: anything leaving the company, anything filed, anything moving money. One paragraph, agreed before anything runs.
• A decision on where data lives. For most companies, hosting inside the European Union with a processing agreement in place; for some, stricter, and that decision is easier made before the first document is uploaded than after.

Data, law, trust

The interface layer processes personal data: names on invoices, employees in onboarding, clients in contracts. The basics apply and are not optional: a data-processing agreement with whoever operates the layer, stated retention periods, EU hosting or a documented reason for anything else, and access limited to the people who need it. Nothing here is new; the layer must simply meet the standard the company already owes.

Two things the layer must never do. It must never file anything with an authority on its own; declarations are human acts, as chapter 4 argued, and the layer's job ends at a prefilled, sourced draft. And it must never replace the originals: legal retention rules for accounting documents continue to apply, and the layer keeps originals and links to them, it does not stand in for them.

Pitfalls that are specifically Romanian

The tax id in several spellings. With and without the country prefix, with and without spaces, occasionally with a typo carried for years in someone's address book. Normalize at tier zero and match on the normalized form, never on the string as it arrived.

Diacritics. The same company name with and without them, from different sources. A resolution step that treats them as different names will create duplicates for months.

The messaging group as a system. If invoices, delivery confirmations, or client instructions arrive on a messaging app, that app is a system in the inventory, with its own seam. Pretending it is not is how the layer misses a third of the traffic.

Closed software with no API. Some local accounting and ERP programs expose nothing. The seam then runs through their human-readable exports and imports, which is slower and still far better than a person retyping. The layer's job is to prepare exactly the import the program accepts.

The certificate and the token. Access to the national e-invoicing system is authorized with a qualified certificate and lives on tokens that expire. Whoever operates the layer must refresh them ahead of time and tell you when it cannot. Ask about this before day one; it is the single most common reason an automatic pull stops quietly.

Where we fit, and where we do not

We build one implementation of the layer, and the series was written so that a company could apply it with any implementation. Ours today reads documents, scans, and e-invoices pulled from SPV once the company's account is connected, a step we do together at onboarding. It fills and updates data tables from what it reads, reads and writes Google Sheets and Drive, calls systems that expose an API from scheduled workflows, answers questions with the source document and page attached, and stops at the confirmation boundary before anything leaves. What we do not have: ready-made connectors for specific Romanian ERP and accounting programs, and the broader write-back that comes with them. We are choosing those by what pilot companies actually run. If you make the two inventories from chapter 1 and chapter 4, they are the first thing we would like to read.

The person who did this work

The series began with one person: the office manager, the dispatcher, the accountant, whoever ended up carrying information between systems that never learned to talk. Five chapters later the argument is simple to state. The judgment they applied at every seam can now be taken by a layer that reads, resolves, proposes, and writes back, provided the company measures it and keeps a person at the boundary. Nobody is replaced: the person is freed from the mechanical half of the work and kept exactly where their judgment matters, at approval, at choosing, at owning the outcome. The hours that return are the hours nobody hired them for.

The inventory is the first page. Everything else follows from it.