Custom software integration: connecting the systems you already use

Custom software integration is software built to connect the systems your company already runs, so that when something changes in one, every system that needs the change hears about it without anyone retyping it. Done well, a sale, a timesheet or a supplier bill is entered once and reaches the right ledger with a record of how it got there.

This guide covers the connections themselves; for the stages of a build, see our guide to the custom software development process.

What does custom software integration mean?

A mid-size or large company rarely runs one system. Accounting, the company-wide operations system, the warehouse, payroll, the customer system, timekeeping and purchasing each keep their own records, often separately for each entity.

Between them, people do the integrating: keying exported hours into payroll, copying a new customer into each entity's books, checking a warehouse receipt against the purchase order. Each handoff costs time and invites a typo.

Integration replaces those handoffs with rules. When a record changes in the system that owns it, a message goes to the systems that need it, in a format they accept, with a record that it arrived. The National Institute of Standards and Technology (NIST), in its guide to managing the security of information exchanges, says such exchanges need managing between separately managed parts of one organization, not only between organizations.

If your systems are really one operations system in pieces, see our guide to custom enterprise resource planning (ERP) software.

What are the common ways to connect systems?

There are four patterns, and most companies use more than one. A direct connection uses the other system's published interface, what developers call an application programming interface (API).

Pattern	How it works	Fits when	Watch for
Direct connection	One system calls the other's published interface, or gets a message when a record changes	Records that must be current within minutes	Every new system adds connections to build and watch
Scheduled file exchange	One system writes a file on a schedule; the other loads it	Older systems, payroll and bank files, overnight batches	A file that doesn't arrive, or arrives twice
Central hub	Each system sends changes to one hub, which checks and passes them on	Many systems sharing the same customers, items, employees or entities	One more system to run and watch
Read in place	One system looks the record up in the other when it needs it	Stock on hand, credit status, an employee's department	The other system has to be up when the lookup runs

The NIST exchange guide's own example of a scheduled transfer is weekly payroll information sent to a payroll provider "every Friday evening." Reading in place limits what it warns copying can bring: "duplicative datasets, outdated information, or an increased risk of unauthorized disclosure or modification."

An old system with no published interface can often still export files. If it can't be connected safely at all, see our guide to legacy system modernization.

Which system is the source of truth for each record?

Most integration problems trace back to this decision. For each kind of record, one system owns it and the others receive copies. A common split, as an example rather than a rule:

• Customers and terms: the customer system or accounting, not both.
• Items, prices and jobs: the operations system.
• Stock on hand: the warehouse system.
• Employees and pay rates: payroll or the human resources system.
• Approved hours: timekeeping.
• The general ledger: accounting, always.

Go down to the field where needed (the customer system may own the contact, accounting the credit terms), and decide whether edits to a copy are blocked or overwritten.

More than one entity adds questions. Is a supplier one record shared by every entity, or one per entity? How does each location map to each entity's accounts? NIST's planning list asks the same: whether the systems name their data elements compatibly, and whether ownership of exchanged data moves to the receiver or stays with the sender. Write the answers down before anyone builds.

What happens when a message fails?

Every connection fails sometimes: a system is down for an upgrade, a password expires, or accounting rejects a bill for a closed period. Plan for each case:

1. Temporary failures retry on their own, with a longer wait each time, then alert a person.
2. Retries never create duplicates. Each record carries a unique reference, so a resend is recognized instead of posted twice.
3. Rejected records go to a queue with the reason, for a named person to fix. Nothing is dropped silently, and conflicts are never guessed.
4. Silence counts as a failure. A nightly file that doesn't arrive raises an alert.
5. Checks run before data goes in. NIST's catalog of security and privacy controls calls for checking the validity of inputs, and for predictable, documented behavior when an input is invalid.

When the same error keeps coming back, fix the cause. The catalog says resolving input errors includes "correcting systemic causes of errors and resubmitting transactions with corrected input."

How should permissions and the audit trail work?

An integration is a user with access to several systems at once, so treat it like one. Give each connection its own account, never a person's login, and only the access its job needs. NIST's glossary defines least privilege as limiting the access of users, and of processes acting for them, to "the minimum necessary to accomplish assigned tasks." The connection that sends hours to payroll has no reason to post to the general ledger. Keep those accounts in your company's name, so access stays with you.

Keep the approvals you already have. A supplier bank change or an entry into a closed period still waits for the person who approves it today.

Then keep an audit trail a controller or auditor can follow. The NIST catalog asks for audit records that show what happened, when, where, the source, the outcome and who was involved. Every record should trace from the sending system to the entry it became, with who approved it.

How do you test an integration before it goes live?

The NIST exchange guide says to "test the interface between applications across the exchange, and simulate data traffic at planned activity levels to verify correct translation at the receiving end," ideally away from the live systems. In practice:

• Use last month's real records, including the awkward ones: a customer billed by two entities, a credit memo, hours that cross a pay period.
• Reconcile totals by entity and account. What left one system should equal what arrived.
• Test at month-end volume.
• Break it on purpose. Switch off the receiving system, send a bad record or the same one twice.
• Have the record owners sign off: the controller for the ledger, the payroll lead for payroll.

Real data carries real risk, so the NIST catalog says to "approve, document, and control the use of live data" in test environments, and to protect them at the same level as the live data in them. For the first cycle, consider running the manual process alongside and comparing results.

Who watches it after launch?

Someone has to, by name. NIST recommends closely monitoring a new exchange "for an agreed upon period" after it starts. Its ongoing list includes analyzing logs, managing changes and checking whether the exchange is still needed.

Integrations usually break because one side changed: an upgrade, a new required field, a renamed cost center, a new entity. NIST suggests testing planned changes away from the live systems and telling the other parties in writing. Agree on:

• A business owner for each data flow, such as the controller for the ledger.
• A technical owner who gets the alert and fixes it.
• A monthly review of what ran, what failed and what is held.

When a system is retired, NIST describes ending its exchanges "in a methodical manner to avoid system disruptions."

How does Raileon handle custom software integration?

We build and run custom software around how your company already runs, including the handoffs between systems that don't talk to each other, so nobody types the same order twice.

It starts with a free 20-minute call with the founder, then a check of which systems hold the data and how they can be reached: a yes, no or "needs work" for each. A written proposal sets out the data flows, approval rules and exact price, before anything starts. Each connection gets only the access its step needs, conflicts are held for a person, and every sync is on record. We test on real examples from your business first. Where a step needs judgment, such as reading a supplier's invoice, our AI integration services handle it, and nothing moves money until someone on your team says yes.

After launch, a failed step or an expired connection alerts your Raileon team. The build is priced by scope. Monthly care (hosting, monitoring, fixes and updates) starts from $1,999 a month. Cancel any time. Your plan runs to the end of the month you've paid for. No exit fee.

Each client's data is kept separate, encrypted in transit and at rest, and backed up daily. We never use your data to train AI models, unless you hire us to train your own model. Our terms are plain: Raileon owns the code it builds, and your data stays yours.

FAQ

What is custom software integration?

It is software built to connect the systems a company already runs, so a change made in one reaches the others without anyone retyping it. It also covers the rules: which system owns each record, what happens on failure and who can see what.

What do custom software integration services include?

They should cover which system owns each record, the connections, failures and retries, permissions, an audit trail and testing with real records. Good services also watch the integrations after launch and fix them when a connected system changes.

Do we need a central hub, or are direct connections enough?

A few systems can usually be connected directly. Once many systems share the same customers, items, employees or entities, a central hub that passes data between them is easier to watch and change.

Can you connect a system that has no published interface?

Often, yes: many older systems can export and import files on a schedule. If a system can't be connected safely at all, that is usually a sign to plan its replacement.

Where are your people retyping data today?

Bring the list of your systems and the places where data gets typed twice. On a free 20-minute call, we'll tell you which connection to build first.

Book a free 20-minute call