All writingUloborus · 6 min read

Compliance paperwork should fall out of the transaction, not be typed again

The invoice, the e-way bill and the goods that actually left the gate are one event recorded three times. That arithmetic is what month end is really paying for.

Postgresorchestrationdata contractsAirflowApplications and automationGovernanceManufacturingLogistics

At the end of every month, in a great many mid-sized plants, somebody sits down with two exports open side by side. One is the despatch register from the production system: what left the gate, on which date, against which batch, in which vehicle. The other is the sales register from the accounting package: invoice numbers and values. The job is to make the two agree. It takes two or three days. Nobody has ever costed it, because it is paid in overtime rather than in a line on a budget.

The two lists differ for boring reasons. An invoice was raised for a load that was later held back. A despatch was entered the following morning and sits on the wrong date. One lorry carries two invoices because the first went to the wrong customer code and was reissued. A rejected consignment came back and was credited against a reference nobody can now find. None of this is fraud or incompetence. It is the ordinary residue of one physical event having been typed into two systems by two people who were not in the room together.

That is the whole cause, and it is worth stating flatly before anyone proposes a faster reconciliation tool. The registers disagree because the movement of goods and the paperwork about the movement of goods were recorded separately. A better matching engine makes the disagreement quicker to resolve. It does not stop producing it.

The document and the movement are one event

A load leaves the gate. Under GST that single physical fact is obliged to produce a tax invoice, an invoice reference number from the registration portal if the business is above the e-invoicing threshold, an e-way bill carrying the vehicle number, and in due course a line in the outward supplies return. If the goods are going out for job work rather than sale, it produces a delivery challan and eventually a reconciliation of what came back. Every one of those documents is a projection of the same event, seen from a different angle.

Recorded properly, there is one row and several views of it. Recorded the way most plants actually work, there is a row in the production system created by the despatch clerk, and a separate row in the accounting system created later by someone in accounts reading a paper copy of the first. Two authorities, one truth, and a standing obligation on a human being to keep them in step.

Reconciliation is not a task. It is the interest payment on a decision to record one event twice.
The pattern, stated plainly

Two contrasting diagrams. On the left, a gate-out event and an invoice drawn as two separate boxes in two separate systems, joined by a dotted line labelled 'a person, monthly'. On the right, a single despatch event box with solid arrows fanning out to invoice, IRN acknowledgement, e-way bill, batch ledger and GST return. — The same set of documents, produced two ways. Only one of them creates a monthly job.

What falling out of the transaction actually means

01
One event, one keyThe despatch is a row created when material is physically issued against a vehicle. Invoice number, IRN, e-way bill number, batch numbers, weighbridge reading and gate-out time are attributes of that row. Nothing downstream is permitted to create a despatch. Everything downstream reads one.
02
Documents are rendered, not enteredThe invoice is a rendering of the despatch row against the pricing and tax masters. If the rendering fails, that is a defect in a master or a rule, and it is visible at the gate while the lorry is still there. It is never fixed by typing something different into a second system.
03
The portal call is an outbox rowRegistering an invoice or raising an e-way bill is a call to a system you do not control, and it can succeed at the far end while your process dies before it hears the answer. Write the intent into an outbox table in the same database transaction that records the despatch, then let a worker drain it using a client-generated reference, so that a retry cannot mint a second document for one movement.
04
Keep what came backThe signed payload, the acknowledgement number and date, the QR string. That is the authority's version of the event, and it is what any later query will be compared against. Store it whole. A parsed subset is a summary, and in a dispute you want the original.
05
Reversals point at the originalA rejection, a short receipt or a rate correction is a new event carrying the key of the one it amends. The credit note then falls out of that event exactly as the invoice fell out of the despatch, and the link between them is data rather than a sentence in a narration field.

Five mechanics. None of them is clever, and all of them are usually missing.

A despatch row and an outbox row inside one database transaction box, a worker drawing from the outbox and making a single call to the registration portal, the acknowledgement number, signed payload and QR string stored whole underneath, and a lower panel describing what happens when the process dies before it hears the answer: the portal has already registered the document, the outbox row is still unacknowledged, and the worker retries with the same client reference. — The client-generated reference is the whole trick. It is what makes a retry safe, and it is what stops one movement producing two documents.

The masters decide whether this survives

Generating the paperwork at the point of despatch has one unavoidable consequence. Every weakness in the reference data now stops a lorry. Data that was previously corrected quietly in accounts, three days later, at leisure, is instead exposed in front of a driver who is being paid to wait.

Customer GSTIN, registered address, place of supply, and the ship-to that is genuinely different from the bill-to. Place of supply decides which tax heads appear on the invoice, and nobody standing at a gate is in a position to catch it.
Item HSN, rate, unit of measure, and the conversion between the unit you produce in and the unit you sell in. Plants that weigh in kilograms and sell in bags carry that conversion in a spreadsheet more often than they will admit in a meeting.
Transport Vehicle number, transporter, distance, and the validity that follows from it. When a vehicle is swapped mid-journey the update has to land on the same record, not in a message to the accounts team.
Pricing Contracted rate, discount scheme, and whether tax sits on the pre-discount or post-discount value. A pricing rule that lives only in a sales manager's head cannot render an invoice.

This is the real reason plants revert. Somebody has to own the masters and be reachable when the gate calls. If that ownership is not assigned to a named person before go-live, despatch will start keeping a paper pad again within a fortnight, and you will be back to two records with an extra system to maintain. We build Uloborus with its modules over one set of records for this reason, but the records still have to be somebody's job.

When this is the wrong answer

If finance already posts into an ERP that the business treats as the system of record, and that ERP can genuinely hold a despatch with batch and vehicle detail, the honest recommendation is to feed it better rather than to stand a second transactional system beside it. Two systems that each believe they own the sales document is a worse place to be than the one you started from. Integration at the point of despatch, with the ERP still issuing the document, gets most of the benefit and starts no turf war.

Scale matters as well. A unit doing twenty or thirty despatches a month has a reconciliation that takes an afternoon and a memory that covers the whole month. Rebuilding its despatch process to save that afternoon is not a good trade. The arithmetic turns somewhere around the point where no single person can any longer hold the month in their head, which in practice is when loads become daily and multi-vehicle rather than weekly.

2–3 daysat every month endmaking the despatch register and the sales register agree. Paid in overtime, so it has never appeared on a budget.

20–30despatches a monthbelow that, one person still holds the whole month in their head and rebuilding the despatch process is not a good trade.

2 weeksbefore the paper pad comes backif nobody is named to own the masters and answer when the gate calls, despatch quietly goes back to paper.

Month end becomes a test that runs nightly

Once there is one record, the month-end question changes shape entirely. It stops being an act of matching and becomes a set of assertions that either hold or do not. Write them as queries against the despatch table and its documents, and put them on a schedule.

Every gate-out has exactly one active document, and every active document has a gate-out.
Every registered invoice has an acknowledgement stored against it, and the value on the acknowledgement equals the value on our row.
Every e-way bill's vehicle appears in the gate log for the same day, and none has expired while its consignment is still shown as in transit.
Every credit note names an original document that exists and has not itself been cancelled.
The outbox is empty, or every row still in it is younger than the retry window.

None of that needs a person, and none of it needs to wait for a month to close. It is a handful of queries on a nightly schedule, and the contract between the plant system and the finance system is exactly the list above. The value is not that a machine does the checking. It is that a break surfaces on the day it happens, while the driver is still reachable and the despatch clerk still remembers the lorry, rather than three weeks later when the only surviving evidence is a file of carbon copies.

What is left at month end then is not a reconciliation. It is a short list of exceptions that were already known about, each with a name against it and most of them already closed. The two or three days do not get shorter. They stop existing, and so does the overtime that was quietly paying for the whole arrangement.