YORI-ID

Revenue ledger and settlement per branch

A mission accountant today reconciles three sources that do not talk to each other: revenue declared at the counter, collections from the payment provider, and receipts issued. Here there is no reconciliation to perform: the same system takes the payment, issues the receipt and writes the ledger.

One view of all revenue

The ledger brings together all of the mission's revenue — cards, documents, passports — whatever channel it came in through: online payment, but also cash, transfer, cheque and the counter payment terminal.

A finance department thinks by revenue, not by channel. Accounting that separates online from counter forces two statements to be added up by hand, which is precisely the work we set out to remove.

  • Paginated multi-criteria search across every entry
  • Totals kept by currency
  • A traceable settlement reference on every line, whatever the channel
  • Declared methods the consulate can enable — cash, transfer, cheque — the terminal remaining the only reference verified server-side
Accounting ledger: twenty-five entries, broken down by type and confirmation method, with counter and online revenue in a single view
Cards, documents and passports in one set of accounts, collected at the counter and online alike. The first two rows are waived acts: they appear at a zero amount. Names, member numbers and card number are redacted.

The export is the document you hand over, not a starting point

The export produces a two-tab workbook: a summary by type and channel, and the detailed entries.

It is what the accountant passes up the chain without reworking it. An export that still demands half a day of formatting has not done half the work, it has moved it.

The mission's share is never mixed with fees

Two amounts coexist everywhere and are never conflated: what the mission receives — the consular price — and what the payer actually paid, transaction fees included.

The ledger is kept in net terms to the embassy. The payment provider's fees do not appear there as revenue, because they are not.

The money lands directly in the branch's own account

Each branch has its own collection account, and its share reaches it at the moment of payment. There is no redistribution to carry out between posts, because there is nothing to redistribute.

The allocation rule is configured per collection type and per channel, the counter having its own schedule. Rates are commercial settings specific to each contract, never a product characteristic.

  • One allocation line per collection: amount charged, price, fees, commission, branch share, currency
  • And the rates applied at that precise moment — a change of schedule never rewrites history
  • The question "which schedule applied that day" no longer arises: the answer is in the line
  • Read-only consultation and spreadsheet export

Receipts: one per settlement, never two

Every collection produces a numbered receipt carrying a signed QR code, verifiable by a third party. Re-issuance is idempotent: asking again for a settlement's receipt returns the same document, and there are never two receipts for one sum.

Cancellation is traced. A cancelled receipt stays viewable, and verification reports it as cancelled — a cancelled document that vanished from the records would be worse than one that says so.

Fee waivers: audited, and at a zero amount

A waiver requires a dedicated role and a stated reason. The waived act appears in the ledger at a zero amount, flagged as granted free of charge.

That is the right way to handle it: it stays traceable — a free act is still an act delivered, and an audit must be able to find it — without ever inflating revenue. Counting a waiver as an entry would mean booking money that was never collected.

The distinction rests on two objects: the document issued carries neither amount nor payment method, so no revenue can ever be recorded on it; the act itself is traced by its zero-amount receipt.

Frequently asked questions

Does the ledger cover counter collections?

Yes. Cash, transfer, cheque and the payment terminal appear alongside online payment, with totals by currency. The consulate chooses which declared methods it accepts; the terminal is the only one whose reference is verified server-side.

Are transaction fees counted as revenue?

No. The ledger is kept in net terms to the embassy: what the mission receives and what the payer paid are two distinct notions, never conflated.

What happens if a rate schedule changes?

Nothing to the past. Each allocation line carries the rates applied at collection time, so a later change does not rewrite history.

Does a fee waiver show up in revenue?

No. The waived act appears in the ledger at a zero amount, flagged as free of charge: it stays traceable without being counted as revenue. A waiver also requires a dedicated role and a stated reason.

Can a lost receipt be reissued?

Yes, and the operation is idempotent: the same receipt is returned. There are never two receipts for one settlement, which rules out double counting.

See also

See YORI-ID on your own scope

A demonstration is built around your actual services, volumes and deployment constraints.

Request a demonstration