Every amount justified and followed through to payment

Why an amount is owed, and what was really paid

For every amount, VisitSoft answers six questions: why it is owed, who owes it, who is entitled to receive it, which real event justifies it, how it was invoiced, and what money actually moved.

The module always keeps what is owed apart from what is paid. It also keeps the direction (what you are owed, what you owe) apart from the reason (dossier fee, purchase, delivery, subscription, reimbursement). Billing works with or without a visit: a payment recorded during a visit is just one way in.

The module's vocabulary

• Receivable: what is owed to your organisation. It is not money received.
• Payable: what your organisation owes someone else. It is not money paid out.
• Fee catalogue: each fee has a code, amount, currency, validity period and tax and refund rules. Every change creates a new version.
• Obligation: the amount owed, debtor, creditor, due date, currency and remaining balance.
• Invoice: the sales invoice you issue, or the supplier invoice you register. A quote or proforma does not create a receivable.
• Transaction: a real movement of money, in or out, with its payment method, confirmation and evidence.
• Allocation: the part of a confirmed transaction applied to one or more obligations.

Customer side: from service to receipt

• Reception chooses the person or organisation, the service and the fee from the catalogue.
• VisitSoft creates the obligation and a draft invoice: lines, taxes, discounts, due date. The price comes from the fee in force.
• An authorised user checks the issuer and recipient, then issues the invoice. It receives a final number and a PDF.
• The cashier records the payment: cash, Mobile Money, card or transfer, with its reference and evidence.
• The payment is allocated to the invoice. The balance is recalculated, and a partial payment or an overpayment is handled explicitly.
• A numbered receipt is produced, and the paid or partly paid status is visible.

Supplier side: from delivery to payment

• Reception records the delivery and the proof of receipt. A delivery received never authorises a payment.
• Finance registers the supplier's invoice. It uploads the original PDF or photo, then hands over a receipt (décharge) with a follow-up number (VS-AP-…). Assisted reading (OCR) suggests the fields to check.
• The manager compares the quantities delivered, the prices and the invoice. They confirm, dispute or reject.
• An approver authorises the payable within the set thresholds. The person who approves is not the person who entered it.
• The payment is recorded with its evidence (Mobile Money receipt, transfer order), then confirmed by someone else.
• It is allocated to the payable, the balance is updated and a payment voucher is produced, with the full history.

Everyday situations

• Partial payment: one invoice receives several payments. The balance comes from allocations, never from a status set by hand.
• Consolidated payment: one transfer settles several invoices, and each share stays traceable.
• Advance or deposit: the money stays available until it is allocated, and is never counted twice.
• Refund: linked to the original payment, with its reason, approval and evidence.
• Credit or debit note: an issued invoice is never edited. A linked document is issued with its own number.
• Recurring billing: one invoice per period, at the rate in force for that period.
• Fee without an invoice: where your policy allows it, the direct payment stays linked to an obligation.
• Online payment: each notification from the provider is verified and reconciled before it is confirmed, and a notification received twice is counted once.
• No visit: billing a customer or paying a supplier doesn't need a visit. A visit can be linked later.
• Several deliveries: one supplier invoice can cover several accepted deliveries. Disputed lines are not paid.

Invoices, templates and taxes

Drafts, quotes, proformas and invoices are calculated by the server, line by line, with discounts and taxes. The number is allocated only at issue, with no gaps or duplicates. At issue, VisitSoft keeps a frozen copy of the data, the template version and the PDF's fingerprint: an issued invoice stays identical even if your logo or layout changes later.

Invoice templates belong to the issuing organisation. They carry your logo, colours, legal mentions and payment instructions, in French and English. Tax rates are entered with their period of application, then activated by someone else.

Recurring due dates and reminders

Each obligation is one-off or recurring: daily, weekly, monthly, quarterly, half-yearly, yearly or on your own calendar. Month ends, leap years, pauses and restarts are handled without duplicate invoices.

Reminders go out before the due date (for example 14, 7 and 1 day before), on the day, and when overdue. They use the app, email, and SMS or WhatsApp where configured and permitted. They work in both directions: reminders to customers for your receivables, approval and due-date alerts for your payables. A reminder is never a payment.

Organisations and their representatives

Every payment to a business or institution goes to a registered, verified organisation. Its representatives are linked to people already known in VisitSoft, with their role (sales, delivery, signatory, authorised payee), their authority and its expiry date.

A representative is not the payee by default: the courier who brings ten laptops is not authorised to collect payment. A change of bank account or payee is put on hold until it has been verified twice, with the old and new values kept.

Controls at every step

• Payer, payee, issuer, recorder and approver are separate fields. Nothing is assumed from the visitor in front of you.
• Roles are separate: reception starts the request, the cashier collects and issues the receipt, billing issues, finance verifies and allocates, an approver authorises payables and refunds, and the auditor reads without changing anything.
• Sensitive steps need two different people: nobody approves their own work.
• Approval thresholds are configurable, and every action is permission-checked.
• The history cannot be rewritten: every cancellation, correction or reversal creates a new record, and nothing is deleted.

Working with the visit

An external activity is attached to an incoming or outgoing visit. An internal activity, such as processing a supplier invoice in the office, needs no visit. For example: a customer comes in, pays a dossier fee, gets a receipt and leaves; or your team goes out to pay a supplier on site, records the payment and the person who received it, then comes back.

Closing a visit settles nothing: an unpaid amount stays open after the visitor has left.

Follow up and decide

Dashboards show receivables and payables by age, invoices, fee collections, settlements, upcoming due dates and exceptions. Totals are filtered by issuing organisation and currency, and the data exports to your accounting.

Payables reconciliation finds exceptions on its own: a pending payment with no evidence, a confirmed payment never allocated, allocations larger than the payment, or a payable whose status no longer matches its payments. Each exception can become a review case, with an owner, a severity and a deadline. A case cannot be closed while the exception still exists.

The owner gets a reminder before the deadline and again when it is overdue, and overdue cases are escalated to finance managers in two levels. A summary of payables by currency and the list of exceptions export to CSV.

What VisitSoft does not do

VisitSoft does not move money: it records, justifies and reconciles payments made through your usual channels. It doesn't replace your general ledger, payroll or bank reconciliation, and it doesn't compute tax for you: it provides the supporting evidence.