Foreign-currency reconciliation
A deposit in dollars or euros against a policy in pesos, dollars, or euros, with a dated conversion.
orbit cashmatch reconciles foreign-currency deposits against policies in another currency: it reads the bank document, runs nine rules across three layers, and applies the payment using the exchange rate of the day the money arrived. Every decision keeps the evidence behind it. Today it is a proof of concept with the real services already wired in.
The collections desk receives a deposit in dollars and has to decide which policy it belongs to. The bank sends a SWIFT with no clear reference, or a statement with the payer's name misspelled. The policy is in another currency, so it must be converted, and converted at the rate of the day the money arrived, not today's. Someone does that by hand, and when the auditor asks why that deposit went to that policy, the answer lives in that person's head.
A three-layer probabilistic reconciliation engine. It reads the bank document, extracts the fields, and runs nine rules against the universe of policies: deterministic first, programmatic next, and only when those fall short does it escalate to a language model with the best candidates. Every result carries its score, the textual evidence behind each rule, and the exchange rate it used with its date.
From the bank document to the applied payment, with the evidence kept at every step.
A SWIFT, a statement, a receipt, or a loose PDF. It is read with the document extraction service and its fields are structured.
Nine rules score every candidate: exact reference, converted amount, time proximity, payer similarity, currency corridor, counterparty, tax ID, and account.
Above the threshold the deposit applies itself. If not, it escalates to the language model with the best candidates, and if it still does not resolve it goes to human review. The engine invents nothing.
Every match records which rule contributed what, with which text, and with which exchange rate from which date. The whole run exports to Excel.
The modules that exist today and run with the real services wired in.
A deposit in dollars or euros against a policy in pesos, dollars, or euros, with a dated conversion.
The deposit applies itself when the score clears the threshold the organization configured.
What the engine cannot resolve reaches a person with its candidates and score, not blank.
Anyone can reconstruct why that deposit went to that policy, rule by rule.
Rule weights and thresholds move from the interface and the next run uses them.
The run exports to Excel with a summary, the matches, event-by-event traceability, and the rates used.
Five differences from reconciling foreign-currency deposits by hand.
Request demoIf the deposit arrived on 28 April, the conversion uses the Banxico FIX of 28 April. That is accounting traceability, not an approximation.
Deterministic, programmatic, and only if needed a language model. You pay for the model on the hard cases only.
With no candidate inside the time horizon, the deposit goes to human review instead of landing on the closest-looking policy.
Every rule leaves the text that triggered it, so the audit does not depend on anyone's memory.
Weights and thresholds change from the interface. No ticket, no waiting for the next release.
An honest comparison between how your team reconciles today and with orbit cashmatch.
Built for foreign-currency premium collection. The architecture serves any reconciliation of deposits against receivables.
It is the process the proof of concept was built for.
Applicable by architecture. No case yet.
The foreign-currency portfolio dashboard, the nine-rule protocol with its hard gates, and the run history with its audit file. Recorded in the platform.
In 30 minutes we tell you whether orbit cashmatch fits your process, what it integrates and what it doesn't, and what a pilot looks like. If it doesn't fit, we tell you that too.
Run the discovery with rocky