Code an internal transfer

Tally Handles Most Of These

A transfer between two company accounts is one movement with two bank rows. It is never income or expense.

Confirmed pairs are posted for you. What reaches you is what Tally would not settle on its own — competing candidates with the same amount, no corroborating evidence, or legs more than three days apart. See How Tally settles transfers and card payments.

Recognize The Pair

A suspected pair carries a transfer match badge and offers Record and Reject instead of the normal Post button.

Check before recording:

• the amounts match;
• the dates are the same or a few days apart;
• both accounts belong to this company;
• the descriptions are consistent with a transfer.

Record It Once

Choose Record. LedgerHQ posts both sides together and confirms Transfer posted on both sides. In Fast Coding the same action is Post pair.

Never post the two rows separately as expense and income. That creates a fictitious expense, overstates revenue, and leaves both registers wrong.

When The Match Is Wrong

Choose Reject when the rows are not the same movement — two unrelated payments that happen to share an amount, for example. They return to normal coding and LedgerHQ confirms Transfer match rejected.

If you rejected a real match, choose Reopen match. LedgerHQ confirms it is reopened for the next evidence sweep.

Common Problems

• Only one side appears. The other account may not be connected, or its row is still pending. Leave the visible row uncoded until the counterpart arrives.
• The row is pending. LedgerHQ waits to record matched pending activity until both sides settle or reach 72 hours. See Understand pending bank transactions.
• It is a credit-card payment. Use Code a credit-card payment — the liability side has its own rules.

Correct A Mistake

Use Undo a posted bank transaction and check both registers afterwards. Do not offset a wrong transfer with a manual journal entry.