本機節點會在傳送資料給主機前，對客戶端應用程式提供的資料進行特定檢查，若檢查失敗則以 Status-Acknowledge（Nack-2） 訊息拒絕。 若資料通過檢查，系統不會回傳任何確認訊息給應用程式（雖然主機稍後可能會回傳）。
若用戶端應用程式提供邏輯單元應用程式（LUA）API，API 的設計可能要求將資料送入應用程式的 LUA 動詞在本地節點檢查資料前才會完成。 因此，本地節點在完成對入站訊息的傳送檢查後，總會回應使用功能管理介面（FMI）LUA變體的客戶端應用程式。 這讓用戶端應用程式能完成 LUA 動詞的處理，並將控制權交還給 LUA 應用程式。
若入站訊息通過本地節點的發送檢查並將傳送至主機，本地節點會向用戶端應用程式發送 Status-Acknowledge（ACKLUA） 訊息以示此情況。 用戶端應用程式接著可以用 OK 回傳碼完成 LUA 動詞處理。 請注意， Status-Acknowledge（ACKLUA） 訊息並不表示資料已成功傳送至主機，或主機已收到資料。 之後可能會接著發送 狀態確認（Nack-1） 訊息，表示主機拒絕了該資料。
若入站訊息在本地節點的發送檢查中失敗，則會像非LUA用戶端應用程式一樣回傳Status-Acknowledge（Nack-2）訊息。 客戶端應用程式接著可以透過非 OK 回傳碼將此情況回報給發送訊息的 LUA 指令的 LUA 應用程式。
若用戶端應用程式提供 LUA API，應等待 Status-Acknowledge（ACKLUA） 或 Status-Acknowledge（Nack-2） 其中之一，決定是否回傳 OK 或錯誤回傳碼給 LUA send 動詞。 若不需要依賴本地節點的傳送檢查，用戶端應用程式可忽略 Status-Acknowledge（ACKLUA） 訊息。
請注意，有些競賽條件下，本地節點無法在回覆用戶端應用程式前完成傳送檢查。 在這些情況下，本地節點會回傳 Status-Acknowledge（ACKLUA），但若在剩餘的傳送檢查中偵測到錯誤，可能會再發送 Status-Acknowledge（Nack-2）。 因此，用戶端應用程式可能會收到 Status-Acknowledge（ACKLUA），隨後接收 Status-Acknowledge（Nack-2），以回應同一入站訊息。
在 FMI LUA 變體的傳輸標頭（TH）中，會使用加速流量指示器（EFI）、目的地址欄位（DAF）及起始地址欄位（OAF）。 其他欄位（包括序列號欄位）則被忽略。 在 FMI 的 LUA 變體 RH 中，除了排隊響應指示器（QRI）和節奏指示器（PI）外，所有欄位皆被使用。
對於入站資料，LUA 版本的 FMI 的第一個位元組是 TH[0]。
以下三幅圖說明了應用程式可傳送的不同訊息的 狀態確認（ACKLUA） 確認協議。
在第一張圖中，應用程式發送一個 Data 訊息，通過本地節點的傳送檢查。
應用程式會發送一則數據訊息，這則訊息通過了本地節點的傳送檢查。
在下圖中，應用程式發送一個 Status-Acknowledge（Ack） 訊息，該訊息通過了本地節點的傳送檢查。
應用程式會發送一個 Status-Acknowledge（Ack） 訊息，該訊息通過了本地節點的傳送檢查
在下圖中，應用程式會發送 Status-Acknowledge（Nack-1） 訊息，此訊息通過了本地節點的發送檢查。
應用程式會發送 Status-Acknowledge（Nack-1） 訊息，該訊息已通過本地節點的發送檢查