Do you file customs declarations for us?
No. We are a software company, not a customs broker, and we hold no customs licence or accreditation of any kind. What we build is the data layer around declarations: capturing and validating the information a declaration needs, keeping the documents and their provenance, and integrating with your broker or with a national system where a technical interface exists. The professional responsibility for what is declared stays with you or your licensed broker, and the system is designed to record who supplied and approved each value.
Have you built freight forwarding software before?
Not a full forwarding and customs platform, and we prefer to tell you that plainly. We have delivered a web based logistics management system with third party integrations and real time shipment tracking for an automotive parts supplier, and a supply chain management system covering inventory, demand forecasting and logistics for a supermarket chain. Both are published clients with verifiable reviews. The transferable experience is integration with awkward counterparties, tracking and reconciliation. Job costing for forwarding and declaration data handling would be new build for us.
Should we build this or buy a forwarding product?
For a conventional forwarding operation, buy. The packaged products in this field are mature, they already carry customs interfaces for many jurisdictions, and matching that from scratch is rarely a good use of money. Building deserves consideration when your job types genuinely do not fit a package, such as project cargo or unusual multimodal work, when you need a bespoke layer over a package you are keeping, or when your differentiation is a customer facing experience the product cannot provide. We will give you that assessment honestly, including when it costs us the build.
Can you connect to carrier and airline systems?
In most cases yes, with effort that varies widely. Some carriers publish usable APIs. Many operate EDI. Several offer only a portal, in which case the options are a negotiated file exchange or screen level automation, which is fragile and we will say so rather than presenting it as an integration. We classify every counterparty during discovery so your estimate is built on the difficult ones rather than on an average that hides them.
How do you handle costs that arrive after we have invoiced?
With accruals treated as a first class part of the job rather than as a correction. At booking the job carries estimated costs. As supplier invoices arrive they are matched against those estimates, and the difference is visible. Anything expected but not received remains accrued, so margin per job is meaningful while the job is still open, and month end does not become an archaeology exercise. Exchange differences are shown separately from operational variance, because conflating them is how people stop believing the numbers.
Does it handle consolidations and groupage?
Yes, and the house to master relationship is part of the core job model rather than an add on. A master shipment carries the carrier booking and the bought cost; each house shipment carries its own customer, charges, documents and margin. Cost allocation from master to house follows rules you set, by weight, volume, revenue or a fixed basis, and the allocation is visible so a house level margin can be explained. Operations that cannot express this in their system invariably manage it in spreadsheets alongside it.
Can it work in multiple currencies and countries?
That is the normal case rather than an extra. Each amount is stored in its original currency with the rate and rate date applied, and reporting figures are derived rather than stored, so an exchange movement is identifiable as such. Multi branch and multi entity operation, with different local requirements and separate reporting, is a structural decision we settle at the start, because retrofitting entity separation later is expensive and disruptive.
How do you keep up with changing customs rules?
We do not claim to. That would be a promise we could not keep across jurisdictions that each change on their own timetable. Instead we build so that declaration rules, commodity code data and validation logic live in configuration that your compliance people own and can update without a code release, and we keep the audit trail of what was declared under which rule version. Where a national interface changes its specification, that is a scoped maintenance task, and we would rather price it honestly than pretend it never arises.
Can our customers see their own shipments?
Yes, and it is usually worth building early because it removes a large volume of status enquiry email. A portal can show bookings, milestones, documents and invoices, scoped strictly to that customer. Two cautions we would raise: only publish estimates whose source and update time you can show, since a stale arrival estimate presented as current damages trust faster than no estimate, and be deliberate about notification rules, because a system that emails on every scan trains people to ignore it.
How does this relate to your transportation management page?
They solve different problems. Transportation management is for an organisation planning and buying movement of its own freight: rating, tendering, routing and freight audit. Forwarding software is for an intermediary selling movement to others: quoting, job costing, documentation, customs data and margin per job. Some operations need both, and they meet at booking and cost data. If you move your own goods, the transportation management system page is the better starting point.
Who owns the code and the data?
You do. Source code, infrastructure configuration, documentation and data are yours, held in your repositories and cloud accounts where you prefer, and we hand over so another team can maintain it. That matters more than usual here because customs documentation carries statutory retention obligations, and your ability to produce a complete historical record must never depend on a continuing commercial relationship with us.
