Evidence and decision map
Map statement imports, invoice records, matching suggestions, reviewer decisions, approval and downstream posting. Identify the authoritative source and owner for each transition.
UI/UX design in Patna for payment records that need a human decision.
GreyBath designs reconciliation workbenches that help reviewers inspect an imported payment reference beside the relevant invoice, see why a match was suggested and resolve exceptions without losing the source or approval trail.
Explore a reconciliation design scope
01 / What we build
Expose the evidence. Make the next action clear.
Reconciliation workbench prototype
Prototype filters, comparison panels, partial allocation, unmatched and duplicate review, accessible selection and recoverable bulk actions with redacted representative data.
Reviewed interaction specification
Document permissions, status language, evidence display, confirmation rules, keyboard behaviour, error recovery and unresolved integration decisions for engineering handover.
City context, honestly stated
For Patna operations teams. Delivered through remote collaboration.
Patna district describes the city as an administrative and educational centre. This scope is relevant to businesses and institutions reviewing many payment references, but it is not a claim about any organisation’s records or a local GreyBath office. The engagement is remote; accounting, tax and legal decisions stay with your qualified advisers.
Show why a match is only a candidate
Place payer reference, date, amount, source batch and invoice evidence together. Highlight which fields agree, which are missing and whether the same reference appears elsewhere; a confident-looking badge must not silently become a posted payment.
Give exceptions a useful next step
Design separate queues for partial amounts, overpayments, missing references, disputed allocations and suspected duplicates. Each record needs a reason, responsible reviewer and a clear way to request more evidence without forcing an incorrect match.
Keep bulk work recoverable
Preview the exact selected records and proposed result before a bulk action, distinguish ineligible items, and preserve item-level failures. Specify undo where valid and a correction or escalation route where the source system cannot reverse an action.
02 / Where it fits
Different responsibilities, one understandable record.
The product should distinguish people who import records, propose allocations, approve corrections and administer access. Similar screens do not justify giving every role the same authority.
Finance and receivables reviewers
Compare source evidence, record a reasoned allocation and return uncertain items for clarification rather than clearing a queue for appearance.
Administrative operations teams
Trace a customer, student or account reference through the review process while limiting the personal information displayed to what the task needs.
Supervisors and approval owners
Review changes with before-and-after values, supporting evidence, requester, time and any required second approval.
Product and engineering teams
Agree which states the interface owns and which are confirmed by the ledger, bank import or existing system, including delayed and failed responses.
03 / How we work
Observe review work. Prototype exceptions. Validate recovery.
Observe a real review session
Use approved redacted records to learn how reviewers find invoices, validate references, identify uncertainty and obtain approval. Record failure points instead of assuming a faster bulk button is the answer.
Prototype the awkward cases
Test one payment against multiple invoices, two similar references, a partial amount, a duplicate import and an expired approval. Make no-match and evidence-request routes as deliberate as the happy path.
Validate decisions and recovery
Ask representative reviewers to explain a proposed match, approve an eligible change and recover from a failed batch. Document findings, remaining financial-rule decisions and engineering acceptance criteria.
Design the decision boundary before polishing a table.
This is interface research and design, not an accounting service, payment collection product or tax recommendation. Coding, bank access, ledger integration, financial rules and production data migration are separate unless explicitly agreed.
Discuss your projectSources, volumes and identifiers
Agree the import formats, invoice and account references, currencies, time boundaries, record volume and masking needed for realistic prototype scenarios.
Authority and correction model
Define who proposes, approves, posts, reverses or escalates each type of action and how a reviewed record differs from a change accepted by the source system.
Dense-table usability and evidence
Specify keyboard use, readable amounts, non-colour-only status cues, selection scope, responsive review, comparison details and the change history users need to explain a decision.
Is this a redesign of our accounting policy?
No. Your authorised finance owners and advisers define allocation, approval, correction, accounting and tax rules. We make those agreed rules understandable in the interface and expose questions that still need their decision.
Can we begin with one queue rather than the entire product?
Yes. An unmatched-payment queue can be a focused first scope, provided we inspect its source imports, invoice detail, approval and downstream posting so the prototype does not hide a dependency.
Will a suggested match automatically mark an invoice paid?
Not by default. Candidate, reviewer-approved and source-system-confirmed states should be distinguishable. Any automation or posting authority needs separate agreement, validation and an appropriate exception path.
Can an incorrect bulk allocation always be undone?
No. Reversibility depends on the authoritative system and approved business rules. We design a preview and clear confirmation, then document whether undo, a compensating correction or escalation is actually available.
Do you need access to live bank or customer data for design?
Usually a representative redacted sample is the better starting point. Any further access must have a defined purpose, permission boundary and handling plan; credentials and unmasked financial records should not be sent through the enquiry form.
Reviewers keep switching between files to explain a balance?