Case Study: Building a Self-Service Accounting Invoice Portal

Many businesses have efficient internal systems but still encounter administrative problems when information needs to pass between different organisations.

In this case, our customer maintained detailed digital records of supplier invoices, linked those invoices to individual accounting entries and supplied the documentation to their external accountants each quarter.

The problem arose when the customer began receiving requests for numerous invoices that their own records showed had already been supplied.

Rather than continuing with a repetitive cycle of searching, checking and resending documents, JUCRA looked at how the existing accounting data could be used to create a better process.

The Original Problem

The customer uses a structured quarterly accounting process.

Supplier invoices are collected throughout the quarter and stored digitally. Each invoice is associated with an accounting record containing information such as:

• Supplier
• Accounting Entry ID
• Invoice number
• Transaction date
• Gross invoice value
• IVA
• Payment source
• Original invoice document

At the end of each quarter, the customer provides the relevant accounting information and supporting invoice documentation to their external accountants.

The problem arose when the accountants later supplied the customer with a substantial list of supposedly missing invoices.

When the customer began checking the list against their own records, several of the requested invoices were clearly already present in the accounting system.

Some had valid accounting Entry IDs, associated invoice PDFs and reconciled bank transactions, strongly indicating that they had already been processed as part of the customer’s quarterly workflow.

Where the Frustration Came From

The immediate reaction could have been to simply locate the invoices again and resend them.

However, this created several problems.

The customer would need to:

• Search for each supplier manually.
• Locate the relevant quarter.
• Confirm the matching accounting entry.
• Find the PDF invoice.
• Attach it to an email.
• Repeat the process for every requested invoice.

This duplicated work that had already been completed.

More importantly, it did not solve the underlying issue.

If the accountants believed an invoice was missing and the customer believed it had already been supplied, both parties needed a simple way of checking the same source information.

Without that, the same situation could happen again every quarter.

Using the Existing Accounting Data

JUCRA reviewed the customer’s existing accounting database before considering any new software.

We found that nearly everything required to solve the problem was already available.

The database already contained structured tables for:

• Supplier records
• Individual expense entries
• Invoice numbers
• Transaction dates
• Gross invoice totals
• IVA values
• Payment sources
• Associated invoice files

In simplified terms, the relationship already existed as:

Supplier → Expense Record → Invoice → PDF

The customer did not need another accounting system.

They did not need to copy the information into a third-party platform.

They simply needed a controlled interface that allowed the accountants to access the existing data themselves.

The Self-Service Portal

JUCRA developed a lightweight bespoke PHP application that connects directly to the customer’s existing MySQL accounting database.

The application was deliberately kept simple.

Its purpose was not to replace the customer’s accounting system.

Its purpose was to provide a narrow self-service interface for external accountants who needed access to supplier invoices.

The portal allows an authorised user to search the accounting database without having access to the customer’s main administration system.

This meant the existing database remained the single source of truth.

Supplier and Quarter Search

The accounting process is organised by quarter, so the search interface was designed around the same workflow.

The accountant can select:

• Supplier
• Year
• Quarter

The supplier field includes autocomplete functionality.

As the user begins typing a supplier name, matching suppliers are suggested automatically.

This makes it much easier to locate suppliers within a large accounting database without requiring the accountant to know the exact stored company name.

The search also supports partial supplier names, meaning a user can search for only part of a supplier name and still locate the corresponding invoices.

Viewing and Downloading Invoices

The search results display the key information needed to identify each invoice.

This includes:

• Accounting Entry ID
• Bank transaction date
• Supplier
• Invoice number
• Gross total
• IVA
• Payment source

Where an invoice document exists, two actions are provided.

View PDF opens the original invoice directly in the browser.

Download PDF allows the accountant to save their own copy.

The invoice files themselves are not exposed using their physical server paths.

Instead, a dedicated PHP handler receives the invoice record ID, checks access, identifies the corresponding file internally and streams the document to the browser.

This keeps the underlying filesystem structure hidden.

Making IVA Immediately Visible

The portal was also designed to make IVA easy to identify visually.

Where an invoice includes IVA, the IVA amount is displayed inside a small green pill within the results table.

Invoices without IVA simply leave the field blank.

This provides an immediate visual indication of which supplier invoices contain recorded IVA without requiring the accountant to open each individual document.

For accounting staff reviewing multiple invoices, this makes the interface significantly quicker to scan.

Spend and IVA Summaries

Each search also produces two summary figures.

This means that an accountant can search for a particular supplier during a specific accounting quarter and immediately see both the total expenditure and the corresponding IVA.

The summary values are calculated directly from the same accounting records displayed in the results.

Handling Legacy Database Encoding

During development we encountered another issue common in long-running business databases.

Some older supplier names contained Spanish characters that had historically been stored using incorrect character encoding.

For example, a company name containing:

ESPAÑA

could internally exist using incorrectly encoded characters.

Simply correcting the text for display was not enough.

If the user selected the correctly displayed supplier name, the database search could fail because the stored value was different.

JUCRA therefore added compatibility logic that:

• Displays correctly formatted Spanish characters to the user.
• Searches for both modern and legacy versions of the supplier text.
• Allows older database records to remain untouched.

The user never needs to know this is happening.

They simply type the correct supplier name and receive the expected result.

Appropriate Access Protection

The information available through this portal consists primarily of low-sensitivity supplier invoice data.

It does not provide access to:

• Customer passwords
• Banking login credentials
• Payment card details
• Website administration
• Server administration

The access controls were therefore designed to be appropriate to the sensitivity of the information while remaining simple for the accountants to use.

Access is limited to approved accountant email addresses and maintained through a server-side PHP session.

The portal itself is read-only.

The application also uses:

• Filtered and validated user input
• Prepared MySQL statements
• Restricted invoice file handling
• Hidden server filesystem paths
• Session checks before invoice documents are served
• Wildcard handling to prevent unrestricted supplier searches

The result is a lightweight access model appropriate for low-sensitivity supplier invoice information without introducing the complexity of a full user management platform.

The Result

The original process looked something like this:

Accountant requests invoice → Customer searches records → Customer finds invoice → Customer attaches invoice → Customer sends email → Accountant downloads invoice

The new process is:

Accountant searches supplier → Selects quarter → Finds invoice → Views or downloads PDF

This removes unnecessary manual work from the customer.

It also gives both parties access to the same accounting records.

If an invoice exists in the database, it can be found immediately.

If it does not exist, the customer knows that the invoice genuinely requires further investigation.

The portal therefore does more than save time.

It removes ambiguity from the accounting process.

Lessons Learned

This project demonstrates several useful principles.

• Administrative problems are often data-access problems rather than data problems.
• Existing databases frequently contain enough information to build useful self-service tools.
• Small bespoke applications can remove repetitive manual workflows.
• External users do not always need access to a complete internal system.
• Read-only interfaces can provide exactly the information required while reducing unnecessary exposure.
• Legacy data issues can often be handled at application level without rewriting historic database records.
• Security should be proportionate to the sensitivity of the information being exposed.

JUCRA Recommendations