Mobile Veterinary Software: A Visit-to-Invoice Demo Checklist

Before choosing mobile veterinary software, ask the vendor to complete one ordinary house call from start to finish. Use your own scenario, on the device you carry. A list of scheduling, records, invoicing, and payment features does not show whether those pieces work together when you are ready to leave a client's home.

This checklist is a demo script, not a claim that every product—including OpenVPM—meets every requirement. It uses fictional patients and test payments. Mark each step demonstrated, needs a workaround, or unavailable. Record the workaround too: an extra spreadsheet or an unfinished invoice becomes part of the system you are choosing.

Set up one call with two animals

Your fictional client, Morgan, has two dogs, Fern and Scout, at the same address. Both have appointments during one house call. Fern has a previous record to review; Scout is new. You charge one travel fee, record separate work for each animal, and dispense two units of a sample inventory item. The item and quantities are operational test data, not treatment recommendations.

At departure, the invoice needs to be ready while one SOAP note remains a draft. Run the call twice: once with payment collected immediately, then with an existing client paying later through an online link. Finally, repeat one action after a connection interruption. Ask the vendor to show the resulting records, not just describe the expected behavior.

Use this checklist during the demo

Check the invoice before finishing the notes

Ask to review the invoice with both SOAP notes still open. Can you correct a quantity or remove an accidental line without losing the associated record? Can you see which animal each charge belongs to? If the system requires separate invoices, ask how it avoids charging the household twice for travel and how the client pays the combined balance.

Keep billable quantities and inventory units explicit. Two billed units should have an understandable effect on stock; a charge described as a package should not silently mean a single item. Ask to see the inventory change and its history. You are testing accounting for the supplied example, not asking the software to decide what to dispense.

Next, leave the visit and find the unfinished SOAP again. Look for a visible draft status, a reliable route back to unfinished work, and a distinction between a saved draft and a finalized record. Decide which departure steps your practice requires and which can remain open. The demo should reveal whether those choices are configurable or require bypassing the normal workflow.

Follow the payment all the way through

A payment button is only the beginning of this test. For the pay-now example, inspect a successful test transaction, its receipt, and the remaining invoice balance. Then test a declined payment. The invoice should still make it clear that money is owed. A manually recorded payment and a processor-confirmed payment should be distinguishable when you review the transaction history.

For pay-later, open the link as the fictional client and check the amount and invoice description before paying. Inspect what happens when the same link is opened again after payment. Separately, ask the vendor how refunds, processing fees, payout timing, and reconciliation appear in the actual account configuration being proposed. Request written commercial terms; do not infer them from a successful demo.

Interrupt the happy path

In a test environment, interrupt a submission or repeat it after an uncertain response. Inspect both the invoice and the processor's test transaction list. A disabled button alone does not demonstrate that a retry cannot create a second charge. Ask the vendor to explain how the system identifies a repeated request and lets you recover when the outcome is uncertain.

For connectivity, separate three questions: can you read something opened earlier, can you make an edit without a connection, and does that edit survive closing and reopening the app? Those are different capabilities. Test reconnection and, if offline editing is offered, a conflicting edit from another device. Do not treat an already-open screen as proof of offline support or offline payment collection.

Add a farm scenario if your practice needs one

A two-animal household does not establish herd support. Add a separate scenario with a farm, a group, and one individually identified animal. Ask how membership changes over time, where group work is recorded, and how the invoice distinguishes a per-head charge from inventory consumed. Require the vendor to show those relationships rather than creating a fictional patient named after the herd.

Where OpenVPM fits today

OpenVPM's current mobile evaluation scope is a controlled, connected pilot for individual-animal workflows. Native herd records and offline operation are not ready. We still need to verify the complete visit-to-payment flow in each proposed pilot configuration; available code is not evidence that every step is ready for a practice to rely on.

Bring one anonymized house-call scenario to an OpenVPM workflow review: how many animals, what must be invoiced before departure, when notes are finished, and how the client pays. We can walk through this checklist together, record what works, and identify the gaps before you decide whether to pilot. Keep patient and client identifying information out of the initial request.