Switching systems
That is the question a switch actually turns on — not the feature list. So this page is about your data: what comes across, in what order, what the import refuses, and who does the work. Cargonio was built screen by screen against the system you are running now, which is why the answer is shorter than you expect.
The short version
We have a capture of the screens you use, not access to the other vendor's code — so nothing on this page is a claim about how their system behaves. It is an account of what ours does and what a migration onto it involves.
Your parties, agents, airlines, shipping lines, destinations, charge codes and chart of accounts, loaded from files you export. The field names and the screen labels your staff already work to, because the screens were built against them.
Operations and the ledger stop being two places. A finalised freight invoice posts its own journal voucher, rights are granted per screen and per action, and every change is recorded against the person who made it.
Exports out of your current system, an agreed order to load them in, and a dry run per file before anything is written. The first load is ours to do — it is part of the one-time setup, not an extra line.
Moving the data
130 screens carry the same import flow: upload the file, map its columns onto the screen's fields, run a dry pass that validates every row, then commit the valid rows in one transaction. Column headers are matched against the screen's own labels — which are the captions your export already prints — so most files map themselves.
Code files before anything that points at them: parties, foreign agents, airlines, shipping lines, destinations, countries, currencies, commodities, container types and charge codes.
The chart of accounts, then opening balances as at the date you are opening on. This is the part that decides your go-live date, because it wants a clean cut-off.
Open jobs, their documents and the invoices still outstanding. How much history you bring behind that is your call — a year of closed jobs and a year of ledger is a common answer, and the rest stays where it is as an archive.
We do. CodeSummix loads your master data, chart of accounts and opening balances as part of the one-time setup fee, along with company, branch and fiscal-year configuration, print layouts on your own stationery, user roles and training. What we need from you is the exports and someone who can answer questions about your own codes.
After go-live the import screens are yours — the same flow, whenever you want to load a new price list, a batch of parties or a year of history you decided to bring across later.
What you gain
Each of these is something in the software rather than a claim about anyone else's. Open the demo and you can check every one of them yourself.
Finalising a freight money document — a local invoice, an invoice or credit note to or from a foreign agent, other charges payable, a shipping-line refund — posts a balanced journal voucher into the same ledger the cash, bank and journal vouchers write to. Un-finalise it and the posting is reversed.
Every leg posts in PKR, converted at the document's own rate, so the trial balance never adds dollars to rupees.
The reporting library is declared from the source system's own menu labels and grouping — job and party gross profit, outstanding and aging, sales and shipment registers, statements of account, ledgers, trial balance and financial statements.
Each one runs against live data with its own filter page, prints, and exports to CSV.
Access is granted screen by screen and right by right, which comes to 1,268 distinct permissions across the product. Someone can be allowed to enter a voucher but not check it, print an invoice but not void it, or run one report and not another.
The rights are the workflow ones, not a generic four: View, Add, Edit, Delete, Print, Final, Un-Final, Void, Un-Void, Un-Lock, Check, Un-Check, Email, Approved, Opening Balance, Use.
Changes are logged against the user who made them and the workspace they were made in — including a CSV import, which records the file name, the person who loaded it, and how many rows were created, updated, skipped and rejected.
Nothing to install on each machine and no server of your own to keep alive. Updates are deliberately conservative: the database is dumped before every deployment and that dump kept on the server, the app is only in maintenance mode for the migration window, and a deployment never re-seeds or drops your data.
Every list screen exports what it is showing — same filters, same tab, same working context — as a CSV carrying the full field set rather than just the visible columns, so a download re-imports as it stands.
The same path that brings your data in is the one that takes it out again.
What stays the same
A switch is expensive when people have to relearn where everything is. That is the one cost this product was specifically built to avoid — so these rows say "the same" rather than reaching for an improvement.
The entry screens were built field by field against your current forms and then certified against them. The labels are the ones your staff read out to each other on the phone, not a re-imagined vocabulary somebody preferred.
Screens carry the source captions verbatim — "Local Invoices Entry and Printing (Air-Export)", "Invoices/Dr. Notes Received From Foreign Agents", "Refund from Shipping Lines Entry and Printing". A person who knows where something is today still knows tomorrow.
Operations keeps a horizontal menu bar with hover-to-open panels — same top-level items, same groups, same order — rather than being folded into a sidebar that would not hold it.
Reports are listed under the source's own menu labels and in its own groupings, including Reports (MIS) and Reports (Finance) as their own menus. Asking for "the party-wise outstanding" still finds the party-wise outstanding.
Add, Edit, Delete, Print, Final, Un-Final, Void, Un-Void, Check, Un-Check — the rights on the User Roles screen mirror the ones you already assign, because freight accounting is a workflow and a mistake is voided rather than deleted.
Honestly: the same. Jobs still have to be entered, documents still have to be checked, and no system types an airway bill for you. If a demo suggests otherwise, it is a demo.
What we would tell you in the room
A switching page that lists only wins is not worth reading. These are the known limits today, in the same words we use on the FAQ — each one is being worked on, and none of them is a surprise you would find in your first month.
Switching, answered
We will not quote you a number before seeing an export, because the work is set by your data rather than by our software. Three things decide it: how cleanly your current system exports, how many code files reference each other, and when your fiscal year turns. The loading itself is measured in passes — export, dry run, fix, commit — and each pass is quick; agreeing the cut-off date is usually the longer conversation.
It stays exactly where it is. A migration reads copies you export; nothing we do writes to or removes your existing system, so it remains available as an archive for as long as you keep it. What comes across is what you choose to load — masters and balances at a minimum, then as much job and ledger history as is worth carrying.
Yes — they are separate systems and neither writes to the other, so nothing stops you entering a period in both and comparing. Be clear-eyed about the cost: double entry is real work and the two will drift on anything either side edits. Most of the benefit of parallel running can be had by cutting over at a month or fiscal-year boundary and keeping the old system readable behind you.
We do the first load. It is part of the one-time setup fee, along with company, branch and fiscal-year configuration, the chart of accounts and opening balances, print layouts on your own stationery, user roles and training. What we need from you is the exports and someone who can answer questions about your own codes. After go-live the import screens are yours to use whenever you want to load something else.
No, and it would be wrong to say so. 130 screens carry the import flow — the code files, the transaction lists, the job and document screens and the voucher screens. Screens that are enquiries, dashboards or reports have nothing to import into.
You find out before anything is written. Every import runs a dry pass first that validates each row against the same rules the form uses and reports the failures by row and column; you fix the file and run it again. The valid rows are then committed in one transaction, so a file is never half-imported.
Less than a new system would need, because the screens, the field labels and the report names were built against the ones they already use — but not none. Training is included in the setup fee, and there is a live demo on this site that anyone can open and click through before you commit to anything.
A file of your parties or your chart of accounts is enough to see the whole path — mapped, dry-run and committed — against your own data rather than a demo company's. Or open the demo now and click through the screens your team would be using.