직접 입금이 잘못된 계좌로 들어가면,
증거가 누가 수정할지 결정합니다

잘못된 계좌 번호는 친절 문제라기 전에 기록 문제입니다

수표가 사라졌을 때의 본능은 빠르게 수정하고 비용을 흡수하는 것이지만, 누군가 알아차리기 전에 돈이 사라지는 경우가 많습니다. NACHA 운영 규칙에 따르면 ACH 항목은 처리를 위해 전송된 후에는 되돌릴 수 없습니다. 취소는 잘못된 계좌 번호를 포함한 제한된 사유에 대해서만 허용되며, 원래 항목이 발생한 날로부터 5영업일 이내이면서 오류 발견 후 24시간 이내에 전송되어야 합니다(Nacha). 수취 은행은 계좌가 초과 인출되었거나 폐쇄된 경우 자금을 반환할 의무가 없으며, 이는 잘못된 입금이 만드는 상황과 정확히 일치합니다.

이러한 일련의 과정은 급여 전문가들이 현장에서 설명하는 내용입니다. r/Payroll의 "급여가 가장 먼저 비난받는 것이 싫다"라는 제목의 게시물은 돈보다는 그런 반사적 반응에 관한 것입니다. 관련된 r/Payroll 토론은 더 직설적입니다. 한 급여 관리자가 세 자리가 다른 계좌로 250달러를 보냈고, 취소를 시도했지만 잔액이 이미 사용된 것을 발견했으며, 답글에서는 두 번째 지급 여부에 대한 질문이 남아 있었습니다. 한 댓글 작성자가 전체 문제를 요약했습니다: "이런 일을 피하려면 무효화된 수표 같은 증빙 자료를 제공하도록 하세요. 입력을 잘못한 쪽이 책임을 지게 됩니다. 그들이 잘못 입력했다면 그들이 책임이 있습니다."

은행 변경이 정상적으로 작동하는 방식

대부분의 직접 입금 실수는 세 사람의 손을 거치는 짧은 과정에서 발생합니다. 직원은 종이 승인 양식이나 급여 포털을 통해 새 은행 정보를 제출합니다. HR 또는 급여 담당자는 해당 정보를 확인하고 급여 시스템에 입력합니다. 고용주는 ACH 발신자로서 은행에 지급 파일을 전송하고, 수취 은행은 해당 파일의 계좌 번호로 자금을 게시합니다. 이 과정 어디에서도 은행이 계좌 번호가 명시된 사람의 소유인지 확인하지 않습니다.

이 흐름 아래에는 두 가지 요구 사항이 있습니다. 대부분의 주에서는 임금이 전자적으로 이동하기 전에 직원의 서면 동의를 요구하며, 서명되지 않은 승인은 유효한 ACH 승인이 아닙니다. Nacha 규칙은 또한 해당 승인을 보관할 책임을 발신자, 즉 고용주에게 부여합니다. 서명된 양식은 그 자체로 서류상의 형식이 아닙니다. 이는 특정 직원을 특정 지시에 연결하는 문서이며, 분쟁 발생 시 가장 먼저 요구되는 것입니다. 은행 정보가 더 넓은 신규 채용 서류에 포함되어 이동하는 경우, 온보딩 양식 데이터를 직원 데이터베이스로 가져오는 방법에 대한 가이드에서 해당 통합을 다룹니다.

체인이 기억을 잃는 지점

잘못된 계좌 번호가 급여에 도달하는 일반적인 방법은 네 가지이며, 그중 세 가지는 책임이 누구에게 있는지에 대한 흔적을 남기지 않습니다.

• 셀프 서비스 오타. 직원이 포털에 번호를 입력하면서 두 자리를 바꿔 적습니다. 시스템은 업데이트가 발생했다는 사실만 기록할 뿐, 직원이 의도한 내용은 기록하지 않습니다.
• 전사. 종이 양식을 수작업으로 입력하는 과정에서, 특히 MICR 라인이 흐릿한 스캔본에서 발생합니다. 입력하는 사람이 유일하게 오류를 발견할 수 있었던 사람이면서 동시에 비난을 받는 사람이기도 합니다.
• 플랫폼 마이그레이션. 기존 시스템에서는 정보가 정확했지만, 새 급여 플랫폼으로의 이동이나 대량 가져오기 과정에서 손상되었습니다.
• 분할 입금 오류. 파일에 있는 여러 계좌 중 잘못된 계좌에 비율 또는 고정 금액이 할당되었습니다.

프리노트는 일부 급여 시스템이 첫 실제 입금 전에 실행하는 0달러 테스트 항목으로, 검증처럼 들리지만 실제로는 그렇지 않습니다. 이는 라우팅 번호와 계좌 번호가 일부 기관에서 유효한 조합을 이루는지 확인합니다. 계좌가 직원의 소유인지는 확인하지 않습니다. 한 ACH 실무자가 같은 r/Payroll 스레드에서 말했듯이, 프리노트는 "계좌 소유자 정보를 확인하지 않으며, 라우팅/ACH 번호와 계좌 번호가 유효한 계좌 조합에 해당하는지만 확인합니다." 다른 사람 소유의 잘못된 번호는 이 테스트를 무난히 통과합니다.

프리노트는 계좌가 존재하는지 확인합니다. 계좌가 누구의 것인지는 확인하지 않으며, 이것이 바로 분쟁을 시작하게 만드는 실수입니다.

직원이 입금 누락을 신고할 때쯤이면 취소 기간이 이미 지난 경우가 많고, 제출이 이메일 사진이나 종이 양식으로 입력되어 분산 보관된 경우, 원본에 대한 신뢰할 만한 기록이 존재하지 않습니다. 그 시점에서의 책임 추적은 기억 테스트가 되며, 기억은 먼저 말하는 쪽에 유리하게 작용합니다.

나중에 참조할 수 있는 제출 구축

이 해결책은 급여 받은편지함이 일반적으로 동시에 수행하는 두 가지 작업, 즉 직원의 증빙 수신과 그 숫자 입력을 분리합니다. 직접 입금 검증 워크플로우는 제출을 기록하는 채널을 통해 첫 번째 작업을 처리하고, 문서를 다시 입력하는 대신 읽어서 두 번째 작업을 처리합니다.

수집 링크는 ImageToTable.ai 계정에서 생성된 공유 가능한 URL로, 상대방이 계정을 만들거나 로그인하지 않고도 문서를 처리 대기열에 직접 업로드할 수 있게 해줍니다. 링크는 짧은 확인 코드와 연결되어 있어, 링크와 코드를 모두 받은 사람만 제출할 수 있습니다. 실제로 HR 팀은 은행 검증용 링크 하나를 만들고, 직접 입금을 설정하거나 변경하는 직원들에게 보내며, 각 직원은 무효화된 수표, 은행 서신, 또는 은행 앱의 라우팅 번호와 계좌 번호 스크린샷을 업로드합니다. 도착하는 것은 스레드에서 잃어버릴 수 있는 이메일이 아닙니다. 단일 대기열의 파일이며, 제출 자체가 기록입니다.

두 번째 부분은 맞춤 열 추출입니다. 업로드된 이미지를 읽고 수동으로 숫자를 입력하는 대신, 직원 이름, 은행 이름, 라우팅 번호, 계좌 번호, 계좌 유형 등 필요한 열 이름을 입력합니다. AI는 각 업로드된 문서를 읽고 직원당 행을 반환하며, 페이지의 고정 위치가 아닌 의미에 따라 각 값을 찾습니다. 급여에 도달하는 숫자는 직원이 제출한 문서에 인쇄된 숫자이며, 문서는 프로세스에 계속 첨부되어 있습니다. 두 부분 모두 동일한 링크가 다른 기록도 수집하는 경우 더 넓은 수집-추출 워크플로우에 적합합니다.

은행 검증 증빙으로 인정되는 것

라우팅 번호와 계좌 번호가 표시된 캡처된 증거를 제출 기록이 남는 채널을 통해 업로드하면 충분합니다. 종이 양식 자체가 중요한 것이 아니라, 급여 담당자가 실제로 필요한 것은 번호의 출처를 추적할 수 있는 원본이기 때문입니다.

ACH 네트워크를 관리하는 기관인 Nacha는 수년간 무효화된 수표가 필수라는 가정을 없애기 위해 노력해 왔습니다. Nacha 자체 HR 팀도 안전한 급여 포털로 전환하여 더 이상 종이 수표를 수집하지 않으며, 이 변화는 HR 디렉터가 공개적으로 설명한 바 있습니다(Nacha). 핵심은 수표를 요구하는 것이 아니라, 직원이 제출하는 증빙이 기록을 남기는 채널을 통해 도착하도록 하는 것입니다. 동일한 링크로 업로드된 은행 서신이나 앱 스크린샷은 사진을 찍고 입력한 후 휴대폰에서 삭제된 무효화된 수표보다 더 가치가 있습니다.

급여 검토에 사용되는 추출 측면에서는 HR 감사를 위한 급여 명세서 일괄 추출 가이드에서 연말 급여 데이터 추출을 다루고, 급여 대장 추출에서 급여 대장 자체를 처리하는 방법을 설명합니다.

이 워크플로우가 증명하는 것과 증명하지 않는 것

제출을 캡처하고 문서에서 추출하는 것은 전사 문제와 기억 문제를 해결합니다. 수집 링크를 신원 확인으로 바꾸지는 않으며, 그 경계는 명확히 밝힐 가치가 있습니다.

• 접근은 신원이 아닙니다. 확인 코드는 업로드할 수 있는 사람을 통제합니다. 그 자체로 업로더가 해당 직원임을 증명하지는 않습니다. 코드를 비공개로 공유하고, 의도한 범위를 벗어나 퍼진 경우 교체하십시오.
• 추출은 읽을 뿐, 검증하지 않습니다. AI는 문서에 인쇄된 번호를 읽습니다. 라우팅 번호 체크섬을 확인하거나 계좌가 명시된 직원의 소유인지 확인하지는 않습니다. 소유권 확인을 위해서는 마이크로 입금 확인이나 계좌 연결 서비스 같은 은행 측 절차를 사용하거나, 이미 기록에 있는 번호로 직원에게 전화하십시오.
• 오타와 전용은 다른 위협입니다. 숫자 전위는 정확성 문제이며, 해결책은 원본 문서를 캡처하는 것입니다. 사기성 변경은 보안 문제이며, 해결책은 통제입니다: 다중 요소 인증, 알려진 번호로의 콜백, 은행 정보 변경 시 알림. FBI의 인터넷 범죄 신고 센터는 특히 급여 전용 사기에 대해 경고한 바 있습니다.
• 추적 기능은 내장되어 있지 않습니다. 수집 링크는 알림을 보내지 않습니다. 제출하지 않은 사람에 대한 후속 조치가 프로세스에 의존한다면, 링크를 자체 후속 조치와 함께 사용하십시오.

보존은 캡처만큼 중요합니다. FLSA 규정은 급여 기록을 최소 3년, 임금 계산에 사용된 기록을 최소 2년 보관하도록 요구하며(29 CFR Part 516), IRS는 고용세 기록을 4년간 보관할 것을 요구합니다(IRS Publication 15). 서명된 ACH 승인은 자체적인 보관 기대치를 가지며, 직원이 직접 입금을 사용하는 기간과 그 이후 일정 기간 동안 유지되어야 합니다. 급여 기간이 끝나면 삭제되는 제출 기록은 기록이 아닙니다.

동일한 문서 계층이 공급업체 측에도 나타나며, 은행 정보와 보험 증서를 공급업체 기록에 연결해야 합니다. 이는 공급업체 온보딩 문서 자동화에 대한 가이드에서 설명합니다. 직원과 공급업체는 책임이 귀속되는 위치가 다르지만, 두 분쟁 모두 무엇이 언제 제출되었는가라는 동일한 질문에 달려 있습니다.

자주 묻는 질문

이 모든 것이 잘못된 계좌 번호를 불가능하게 만들지는 않습니다. 다만 그에 대한 논쟁을 짧게 만듭니다. 입금이 잘못된 곳으로 가고 제출, 문서, 도착 시간이 모두 한곳에 있으면 대화는 누구를 탓할지가 아니라 무엇을 수정할지에 관한 것이 됩니다. 그 기록이 급여 팀이 급여일 전에 구축하고 급여일 후에 재구성하지 않을 수 있는 부분입니다.