Connect What Works, Replace Only What Must Go
Integration with VNACCS and VCIS customs, MISA accounting, e-invoice providers, banks, delivery partners and the machines on your floor, so a new system does not require abandoning everything that already works.
The instinct of most software vendors is to replace. It is simpler to deliver, easier to support, and it maximises the contract. But a company that has used the same accounting software for eleven years has eleven years of habits, reports, auditor expectations and staff competence invested in it, and none of that appears on a feature comparison.
Integration is the alternative, and it is harder to sell because it is harder to do. It requires understanding two systems rather than one, agreeing which side owns each piece of data, and handling the fact that connections fail at three in the morning and somebody has to notice.
iGlobal does this work because in Vietnam it is frequently the right answer. Customs declarations go through VNACCS and VCIS whatever else you run. Many finance teams are legitimately attached to MISA. Electronic invoicing goes through a registered provider. These are fixed points, and a sensible architecture connects to them rather than pretending they will go away.
What a missing connection costs
The visible cost is double entry. The same container number typed into the customs declaration, the operational system and the accounting package is three chances to be wrong and three people's time. In a forwarding company this is measured in hours per day, every day, forever.
The invisible cost is the delay in knowing. If bank transactions reach the system two days late, receivables chasing is two days behind reality and a customer gets a reminder for an invoice they already paid. Nobody records that as a cost of a missing interface, but that is what it is.
The third cost appears when an integration exists but is unmonitored. A connection that silently stopped three weeks ago is worse than no connection, because everyone is still trusting the data. Integration without alerting is not finished work, and this is the most common defect we are called in to repair.
- The same data typed into three systems by three people
- Bank transactions reaching the system days after they happen
- An interface that stopped working without anyone noticing
- Vendors insisting everything must be replaced at once
The connections we build
VNACCS and VCIS customs
Declaration data prepared from the operational record and the result read back, so the container and declaration numbers are entered once and the clearance status is visible to operations and to the customer.
MISA and other accounting packages
Journal entries exchanged on an agreed schedule with a reconciliation report, so a finance team that is not ready to move does not have to.
Electronic invoice providers
Invoices issued through your registered provider directly from the sales document, with the issued number stored back against the order and failures raised rather than swallowed.
Banks and payment gateways
Statement import or direct connection where the bank offers it, with automatic matching against invoices so receivables reflect this morning rather than last week.
Delivery and logistics partners
Shipping labels created and tracking status pulled back from the carriers you use, so customer service answers from one screen instead of four carrier websites.
Devices, machines and legacy systems
Attendance terminals, weighbridges, production machines and in-house applications connected through their API, file exchange or database, whichever the system actually offers.
How we deliver it
-
1
Interface survey and data ownership 1 to 2 weeks
For each connection we establish what the other system actually supports, which side is the master for each field, and what should happen when the two disagree. That last question is the one that is usually skipped.
-
2
Build and failure design 2 to 6 weeks per interface
The connection is built together with its retry logic, its error queue and its alert, because an interface without a defined failure behaviour is only half built.
-
3
Parallel verification 2 to 4 weeks
Both sides run together and we reconcile the results daily until they match without intervention for a sustained period.
-
4
Monitoring handover 1 week
Your team receives the monitoring dashboard and the runbook for each interface: what the alert means, what to check first, and when to call us.
Who this is for
- Forwarders and importers declaring through VNACCS and VCIS
- Finance teams staying on MISA while operations move
- Companies with a working legacy application they do not want to lose
- Businesses whose staff retype the same data into several systems
Why iGlobal
We will tell you not to replace something
Recommending that you keep a system we did not build earns us less revenue. We do it because a forced migration of something that works is the most reliable way to lose a client's trust in the first year.
Every interface ships with monitoring
Retry logic, an error queue and an alert to a named person are part of the build, not an upgrade. A silent failure is the worst outcome and it is entirely preventable.
Data ownership agreed before code is written
For every shared field one side is the master. Skipping this conversation is why so many integrations end up with two systems overwriting each other in a loop.
The best balance of cost, quality, and service
Integration is quoted per interface with a fixed scope, so you can start with the one connection that hurts most and decide about the rest afterwards.
Three ways to do this, compared
| What you are comparing | By hand, on spreadsheets | Off-the-shelf software | With iGlobal |
|---|---|---|---|
| A system that already works well | Kept, and fed by hand from the new one | Replaced, because replacing is what the vendor sells | Connected, whenever keeping it is the right commercial call |
| A connection stops working | There is no connection to stop | A log file that somebody might read eventually | Error queue, automatic retry, alert to a named person |
| Who owns the interface afterwards | Nobody, because the interface is a person retyping | The vendor, as a part of their own platform | You, with the source code, the documentation and a runbook |
| Cost across three years | Hidden inside salaries, so it never appears in a budget | A predictable licence per user, plus the work it cannot do | Quoted per phase and reviewed with you before each one starts |
| Who holds your data | Scattered across files, inboxes and personal phones | On the vendor platform, exported on the vendor's terms | Your own database, exportable in full whenever you ask |
| When something breaks | The person who built the file, if they still work here | A ticket queue, often in another language and time zone | A named engineer in Hanoi you can reach the same working day |
The two middle columns describe approaches that genuinely work for some companies. Where they win, they win, and we have tried to say so.
What changes after the connections are live
The first change is simply that people stop retyping. Hours per day across several staff come back, and the errors that came with retyping come back too, in the sense that they stop happening. Data entry errors are rarely counted as a cost until they are removed.
The second is that decisions move closer to events. Bank transactions reaching the system the same day means receivables chasing is accurate, clearance status visible to operations means customers are told before they ask, and each of these is a small shift in timing that compounds across a month.
The third change is strategic rather than operational. Once integration is a capability rather than a project, the question of whether to keep or replace a system becomes a calm commercial judgement instead of an all-or-nothing decision made under pressure from whoever is selling the replacement.
- The same data entered once instead of three times
- Bank and clearance status current rather than days old
- Every interface monitored, with a named person alerted on failure
- Systems that work kept, systems that do not replaced
Frequently asked questions
Can you really connect to VNACCS and VCIS?
We prepare and exchange declaration data in the formats the customs system accepts, and read the clearance result back into the operational record. What is possible depends on the declaration software and the access your company holds, so we verify the exact path during discovery and tell you plainly where a manual step remains.
How long can we keep MISA alongside the new system?
As long as it serves you. Some clients exchange journal entries for a year and then consolidate; others have run the arrangement for several years because their accountant is productive and the reconciliation is clean. We do not put a deadline on it, but we do review it annually with you, because maintaining two ledgers has a cost that should be revisited.
What happens when an interface fails?
The failed records go into an error queue rather than vanishing, the system retries on a schedule, and an alert goes to a named person with enough detail to act on. Your runbook says what to check. The design principle is that a failure must be noisy, because the dangerous failure is the quiet one.
Our old system has no API. Is it hopeless?
Usually not. Scheduled file exchange, direct database reads where the vendor permits it, or in the worst case a controlled export and import routine can all work. They are less elegant than an API and they need more careful error handling, but a daily file at a fixed time is still enormously better than a person retyping.
Who owns the integration code afterwards?
You do. Every interface is delivered as a separate module with its source, documentation and the runbook, so another party could maintain it if you ever chose to change supplier. We think that is the correct arrangement and we would be uncomfortable with any other.
Related solutions
Talk to a senior consultant, not a call centre
Tell us what you are trying to fix and we will tell you honestly whether we are the right team for it.