Accounting sources
Your ERP keeps the ledger. Tresora keeps every column of it.
Tresora reads the extract your ERP already produces — SAP, Oracle, Dynamics, Navision or the flat file your own team exports — and holds on to every field in it. Nothing goes back the other way unless you configure it, so the books stay where your accountants keep them.
What we read
What does Tresora read out of your ERP?
One extract, in the shape your system already writes it. A general ledger line-item export, a journal export, an open-items list: whichever layout your team runs today is the layout we take, with its own delimiter, its own date shape and its own decimal mark.
BUKRS;BELNR;GJAHR;BUZEI;BLART;BUDAT;BLDAT;HKONT;BSCHL;SHKZG;WAERS;DMBTR;KUNNR;ZUONR;XBLNR 1000;1400002187;2026;001;DZ;20260814;20260812;0011300000;40;S;EUR;214830,75;;BKST-0814;914-2026-0088 1000;1400002187;2026;002;DZ;20260814;20260812;0012100000;15;H;EUR;138940,25;0000104512;BKST-0814;914-2026-0088 1000;1400002187;2026;003;DZ;20260814;20260812;0012100000;15;H;EUR;75890,50;0000104877;BKST-0814;914-2026-0088
Three lines of one document, and the amounts carry no sign — the direction sits in SHKZG, in a column of its own. That is why the whole row is worth keeping rather than the two fields a cash figure needs: a reader who takes the amount alone books a credit as a debit.
- Columns in the delivery
- 87
- Every field the export writes, whatever your layout carries.
- Columns kept
- 87
- All of them, on the row, whether a module reads them today or not.
- Columns shown above
- 15
- The record is a cut of the row, not the row.
Write-back
Every row
Does every row in the file end up somewhere?
Yes, and the arithmetic is on the screen rather than in a log. A delivery that is short says so on the morning it arrives, not at close, and the row that stopped keeps the reason it stopped.
Rows delivered equals rows landed plus rows rejected. There is no third number and no residual, which is the only version of this claim worth making: a row that disappears quietly is a figure that will be wrong later, somewhere nobody thinks to look.
A rejected row keeps the file it arrived in, the line it sat on and the field that stopped it. Correct the profile or the mapping and it lands on the next pass — the file itself is kept, so the fix never needs another export out of your ERP.
- Rows delivered
- 24,186
- Landed
- 24,122
- Rejected
- 64
- Posting date in a shape the profile does not declare
- 38
- Amount with no debit or credit indicator beside it
- 20
- No document number to attach the line to
- 6
Landed, waiting on a GL mapping118
BUDAT · SHKZG · BELNR
What comes back
What can I do with the ledger once it is here?
Read it as lines rather than as a monthly figure, next to the bank movements that settled them, with the file each one came out of still behind it.
- Lines, not a monthly summary
- Every line keeps its document number, its position inside the document and the company code it was posted under, so two entities’ books never collapse into one figure that neither of them can explain.
- One counterparty across every entity
- Customer and vendor codes differ per company code and per system. They resolve to a single counterparty here, which is what turns who owes whom into a question with an answer rather than a spreadsheet exercise.
- A GL account map you own
- Each account keeps its own number and its own name, and the map says which group category it reports under. It is a setting, with a record of who changed what and when — your accountants decide what an account means; we compute and show the working.
- The trail back to the row in the file
- Every figure carries the delivery, the file and the line it came from, and the file is kept. A trail your auditor can follow is one they can walk backward without asking anybody for a second export.
The ERP goes on being the system of record. What changes is that a figure taken from it can be opened down to the line that produced it without opening the ERP at all.
Beside the ledger
What about the systems that are not the ERP?
A group’s money moves through more than its ledger. Payroll runs, settlement reports from payment service providers, factoring remittances, leasing schedules and insurer statements all arrive as files with their own shape and their own references.
Feeds
- PayrollCSV · fixed width
- 9
- Payment service providersCSV · JSON
- 7
- FactoringXLSX · CSV
- 4
- LeasingXLSX
- 5
- InsurersCSV
- 3
Feeds beside the ledgerEUR 28
Each class gets a profile that describes its file once — where the reference sits, how the dates are written, which column carries the amount. After that it lands the way the ledger does, on the same row model, with every column kept.
We name classes here rather than products, because the systems inside them are yours to choose. A file we have not met yet gets a profile the day one of your entities starts sending it, and that work is ours.
Who it is for
Who is this for inside a finance team?
The controller who has to explain a figure outside the company and wants the line behind it. The shared service center that runs the same export for every entity and needs to know which ones came in short. The CFO who reads the result and opens neither system.
Written for
The extract, field by field
Where this goes next
- Bank connectivity SWIFT, EBICS, host-to-host and API — however your banks send.
- Reconciliation Bank against ledger, with the evidence for every match.
- Intercompany Both legs of every internal movement, netted and explained.
- Multi-entity groups However many companies there are, consolidated without re-keying.
Practical questions
What do finance teams ask before the first extract?
- 01Which ERPs does Tresora read?
- SAP, Oracle, Dynamics and Navision, and any system that can write a file. The connection is an extract rather than something installed inside your ERP, so an export your team already produces for an auditor or for a bank is a perfectly good place to start: the profile describes that file once, and the same layout lands every time it arrives.
- 02Do you write anything back into our ERP?
- Only what you configure. The ledger flows one way by default, and your ERP stays the system of record for it. Where a group does want a posting written back, that is set per entity and per document type, and it goes through the approvals your own controls require.
- 03Do we have to change our chart of accounts?
- No. Every account keeps its own number and its own name, and a map beside the ledger says which group category each one reports under. Changing the map changes how the reports group, never what your books say, and the map keeps a record of who changed what.
- 04What happens to a row you cannot read?
- It is rejected, and the same morning it is visible on Rejected Rows with the file, the line number and the field that stopped it. Rows delivered equals rows landed plus rows rejected, so a short delivery announces itself instead of looking complete.
- 05We run more than one ERP across the group. Does that work?
- Yes. A profile belongs to a file, not to the group, so an entity on SAP and an entity on Dynamics each keep their own layout and land in the same shape. Nothing is normalized by hand on the way in, and the entity a row came from travels with the row.
Send one export. See every column of it.
One journal extract, from one entity, in the shape it comes out today. You get back the lines, the columns and the rows that did not make it, with the reason beside each one.
No change to your chart of accounts, and no posting written back unless you ask for one.