Skip to main content

Reconciliation (/TrexAdmin/Calculations and related pages)

Primary routes

  • /TrexAdmin/Calculations — main reconciliation workspace.
  • /TrexAdmin/DebitCredit — legacy summary route; treat it as part of the same workflow, not as a separate source of truth.
  • /TrexAdmin/Saldo — complementary saldo view for the same external-settlement cluster.

What this area is for​

TrexWallet uses dual accounting.

For pure on-chain flows, the platform can rely on debit/credit invariants per address. For gateways, banks, exchanges, partner channels, and other external operators, reconciliation is different:

  • incoming and outgoing external movements are visible in payment details;
  • operators may settle later, in another currency, or in a separate payment channel;
  • operators record reconciliation ranges and settlements in this admin area.

This area helps operators answer:

  • what is already covered by reconciliation;
  • what is still open after the last covered range;
  • what settlement was received;
  • where the next reconciliation or settlement record must be created.

Operator vs terminal​

Operator​

An operator is the external side that moves or settles money with the platform:

  • bank,
  • acquiring provider,
  • exchange,
  • P2P processor,
  • partner settlement channel.

In the UI, operators group these parties by terminal network type.

Terminal​

A terminal is the specific settlement profile used for that operator.

Examples:

  • USDT TRC20 settlements
  • EUR bank wire settlements
  • Partner A / BTC loan repayments

Reconciliation records point to a specific terminal id, not only to the abstract operator.

Calculation record types​

RangeReconciliation​

Default flow.

  • Covers the next payment record range for one terminal.
  • Typical operator action: close the next slice after the previous reconciliation.
  • The UI should prefill tx_from from the latest tx_to for the same terminal.

ManualRange​

Corrective or non-default range reconciliation.

  • Operator sets tx_from and tx_to explicitly.
  • Use this for backfill, recovery, split ranges, or other unusual cases.

SettlementOnly​

Settlement record without mandatory range coverage.

  • Use this when the platform needs to record the settlement itself, not a normal transaction range.
  • Typical cases:
    • partner loan received,
    • partner loan repayment,
    • standalone external settlement,
    • future-compatible federation debt settlement.

Summary Mode​

The summary layer should answer:

  • which operators and terminals still have pending debt;
  • how much of that debt is only an uncovered tail after the last covered range;
  • how much is already recorded in range records but still has no settlement link;
  • which standalone settlements affect the current open cycle;
  • what the historical settlement total is for the terminal;
  • which receipts reached the system wallet but are still not reconciled;
  • where operators should go next.

Typical summary questions:

  • What changed after the latest covered tx_to?
  • How much open debt is still waiting after the last covered range?
  • What settlement belongs to the current open cycle, and what is just historical total?
  • Which terminal has unreconciled receipts?
  • Which operator is waiting for the next reconciliation record?

The old DebitCredit route belongs here conceptually.

Raw vs base-currency values​

Summary should not collapse everything into one currency blindly.

  • Raw terminal values stay in the terminal currency and reflect real operator-facing amounts.
  • Normalized base-currency values are used for comparison and for the final Open position indicator.

This is especially important when:

  • the terminal works in one currency;
  • settlement arrives in another currency;
  • the project still needs one comparable management view in the project base currency.

In practice the summary table should distinguish:

  • Pending debt
    • open recorded range debt without settlement;
    • plus open tail after the latest covered tx_to;
  • Current settlements
    • standalone settlement records that affect the current open cycle;
  • Settlement total
    • all settlement history for the terminal;
  • Open position
    • base-currency projection of current pending debt minus current-cycle settlements.

Operations Mode​

Operations mode is where staff create and edit records.

Typical fields:

  • terminal;
  • range (tx_from, tx_to) when the chosen type needs it;
  • settlement transaction or settlement group;
  • operator rate;
  • operator fee;
  • file reference;
  • comments and source markers.

This list should stay compact. Secondary details should move to a dedicated record-detail view instead of overloading the table.

Partner Terminals​

If an external partner gives the platform a loan or participates in a custom settlement flow, model that partner through a terminal:

  • create a dedicated terminal/profile in terminal settings;
  • define the settlement address or settlement requisites used for repayments;
  • attach reconciliation or settlement-only records to that terminal.

One partner may have multiple terminals when channels differ by:

  • currency,
  • network,
  • bank/account route,
  • legal or operational profile.

This is the clean way to keep:

  • normal operator reconciliation,
  • partner settlements,
  • future federation-related debt,

inside one reconciliation model without pretending every case is a standard range-based reconciliation.

Verification note​

Generic admin guidance should not promise a universal inline Verify action.

Real verification may depend on:

  • the operator statement file,
  • merchant-specific statement parsing rules,
  • external reconciliation logic supplied by the merchant integration.

So the operator-facing model here is:

  • create the right record type;
  • attach the right settlement or statement data;
  • use customer/project-specific validation where required.