A Nilus auto-match is not an approved journal entry

Define what was matched

Nilus' official record describes auto-matching transactions, reconciling bank balances to the general ledger, and pushing journal entries to an ERP. A match can mean exact identifier agreement, amount and date tolerance, grouped settlement, bank fee, transfer pair, payment-to-invoice link, or a model-supported suggestion. Record the match type rather than treating every linked row as the same accounting conclusion.

The minimum record identifies legal entity, bank and ledger accounts, currency, value and posting dates, statement or API observation, bank transaction identity, amount, counterparty where authorized, ledger entry or open item, source systems, ingestion time, cutoff, match rule and version, tolerance, confidence, one-to-one or grouped population, exceptions, and preparer. A consolidated view should not merge balances across entities or currencies without an explicit translation and elimination basis.

Separate suggestion, reconciliation, and journal

Matched, reconciled, journal proposed, approved, exported, posted, rejected, reversed, and closed are different states. A match may explain an existing ledger entry, clear an open item, or identify a difference that needs a new journal. It cannot decide the accounting treatment, period, account, dimensions, tax, intercompany treatment, documentation, or approval authority simply because the transaction resembles prior activity.

For a proposed journal, preserve source transactions, explanation, entity, ledger and period, debit and credit accounts, amounts and currencies, dimensions, exchange-rate source, attachments, rule or model contribution, materiality, preparer, reviewer, approval, segregation of duties, ERP batch and entry identity, posting response, rejection or reversal, and link back to the reconciliation difference. Sensitive bank and counterparty information should follow authorized access and retention controls.

Prove completion through the close

Recalculate opening balance plus complete activity to the closing bank observation and ledger balance under the defined cutoff. Identify outstanding checks, deposits in transit, fees, interest, sweeps, transfers, returned payments, duplicate or missing feeds, bank corrections, and timing differences. A balanced worksheet can still be incomplete if the feed population, entity scope, or period is wrong.

Test partial settlement, bundled deposits, duplicate transactions, changed reference text, bank fee netting, cross-currency transfer, weekend value date, stale feed, disconnected account, period lock, rejected ERP batch, edited dimension, reviewer override, later bank adjustment, and reopened close. The reviewer should be able to reconstruct why each match was accepted and how every resulting entry reached the final bank, ledger, and close evidence.

Keep Nilus within the source boundary

The registered Nilus source establishes current public positioning across treasury workflows, including cash, payments, accounting, foreign exchange, debt, investments, bank accounts, automatic matching, bank-to-GL reconciliation, and journal-entry connectivity. It does not establish complete source data, match correctness, accounting treatment, reviewer authority, successful ERP posting, balanced books, close approval, control effectiveness, or customer outcome.

Treasury Operations Review reviewed the official record on August 26, 2026 and did not operate Nilus. Buyers should demonstrate one representative difference from bank and ledger ingestion through identity, matching rule, proposed disposition, reviewer challenge, approved journal, ERP rejection and retry, posting, bank and GL reconciliation, close, correction, rollback, retention, and export. Treasury, accounting, tax, legal, control, security, data, and audit owners retain their decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Treasury Operations Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.